Cómo versionar la configuración de tu servidor de MU Online con Git

Todo administrador de servidor de MU Online ya vivió esta escena: el servidor estaba perfecto ayer, alguien ajustó un valor de drop, tocó una tasa de experiencia o cambió una línea de configuración del GameServer, y hoy algo se rompió, pero nadie recuerda exactamente qué cambió. Sin un registro de cambios, la única salida es cazar el problema a ciegas, comparando archivos de memoria o restaurando un backup entero y perdiendo todo lo que vino después. Versionar la configuración con Git resuelve ese problema de raíz. Git es un sistema de control de versiones que guarda el historial completo de cada archivo de texto: quién cambió, cuándo, qué exactamente se alteró, y permite volver a cualquier punto anterior con precisión quirúrgica. Para un servidor de MU, donde decenas de archivos .ini, .txt y .dat de configuración gobiernan el comportamiento del juego, eso es oro. Este tutorial muestra por qué versionar, qué poner en el repositorio y, tan importante como eso, qué jamás poner, cómo configurar un .gitignore adecuado, cómo usar un repositorio privado y cómo revertir cambios con confianza. Los nombres y formatos de archivo citados son ejemplos y varían por emulador/versión, pero el método es universal.

Por qué versionar la configuración

Versionar no es capricho de programador. Para un servidor de MU, entrega beneficios concretos:

• Trazabilidad: cada cambio queda registrado con autor, fecha y descripción. Sabes exactamente cuándo se alteró la tasa de experiencia y por qué.
• Reversión precisa: en vez de restaurar un backup entero, deshaces solo el cambio problemático, preservando todo lo demás.
• Comparación (diff): antes de aplicar, ves línea por línea lo que va a cambiar. Eso atrapa errores de tipeo y valores absurdos antes de que salgan al aire.
• Colaboración segura: si tu equipo tiene más de un administrador, Git evita que uno sobrescriba el trabajo del otro sin darse cuenta.
• Documentación viva: el historial de commits se convierte en un diario del servidor, contando la evolución de las decisiones de balanceo.

Sin versionado, la "memoria" del servidor vive en la cabeza de quien administra, y desaparece cuando esa persona olvida o se va. Con Git, la memoria es del proyecto.

Requisitos previos

• Git instalado en la máquina (descárgalo de git-scm.com; en Windows viene con Git Bash, útil también).
• Acceso a la carpeta del servidor donde están los archivos de configuración.
• Una cuenta en un proveedor de repositorio privado (GitHub, GitLab o Bitbucket): todos ofrecen repositorios privados gratuitos.
• Nociones mínimas de línea de comandos (abrir una terminal en la carpeta y escribir comandos).
• Editor de texto para crear el archivo .gitignore.

No hace falta saber programar. El conjunto de comandos usados aquí es pequeño y repetitivo. Si ya configuraste un servidor siguiendo una guía de cómo crear un servidor de MU Online, la curva de Git será tranquila.

Qué versionar y qué NO versionar

Esta es la decisión más importante del proceso. Poner lo incorrecto en Git provoca desde repositorios inflados hasta fugas de datos.

La regla mental: Git es para configuración de texto que cambia por decisión humana, no para datos operativos que cambian solos. La base de datos es el ejemplo clásico de lo que no versionar: cambia con cada login, con cada ítem dropeado, con cada segundo de juego. Intentar versionar eso llena el repositorio de ruido y además pone datos sensibles de cuentas en riesgo. La base tiene su propio ciclo de backup en SQL Server, separado de Git.

Los binarios también quedan fuera por otro motivo: Git está optimizado para texto. Guarda diffs eficientes de archivos de texto, pero trata cada versión de un .exe como un blob entero nuevo, inflando el repositorio rápidamente. Si necesitas versionar binarios grandes, existen extensiones específicas para eso, pero para configuración pura son innecesarias.

Paso 1 — Inicializar el repositorio

Abre una terminal en la carpeta de configuración del servidor. Lo ideal es versionar una carpeta que contenga los archivos de config, y no la raíz entera con binarios.

cd D:/MuServer/Config
git init
git config user.name "Tu Nombre"
git config user.email "[email protected]"

El git init crea un subdirectorio oculto .git que guardará todo el historial. A partir de aquí, esa carpeta es un repositorio. Las dos líneas de config identifican quién hace los commits, importante cuando hay más de un administrador.

Paso 2 — Crear el .gitignore ANTES del primer commit

Este paso viene antes de agregar cualquier archivo, y es deliberado. El .gitignore es una lista de patrones que Git debe ignorar. Crearlo primero impide que commitees accidentalmente algo sensible ya al inicio.

# Base de datos - NUNCA versionar
*.mdf
*.ldf
*.bak
*.bacpac

# Binarios del emulador
*.exe
*.dll
*.pdb

# Logs
*.log
logs/
Logs/

# Secretos y credenciales
*secret*
*.key
connection.config
credentials.ini

# Temporales
*.tmp
*.bak
Thumbs.db
desktop.ini

Ajusta los patrones a la estructura de tu emulador. Si las contraseñas de conexión con la base viven dentro de un archivo de config que necesitas versionar, la solución es extraer el secreto a un archivo separado (ignorado) y mantener en el repositorio solo una plantilla de ejemplo, como connection.example.ini, sin la contraseña real. Varía por emulador/versión dónde se almacenan las credenciales.

Paso 3 — Primer commit

Con el .gitignore en su lugar, agrega los archivos y haz el commit inicial.

git add .
git status        # revisa lo que sera commiteado ANTES de confirmar
git commit -m "Configuracion inicial del servidor"

El git status antes del commit es un hábito de oro. Lista todo lo que entrará en el commit. Detente y lee esa lista. Si aparece algún .mdf, .log o archivo con contraseña, tu .gitignore está incompleto: corrígelo antes de confirmar. Un secreto que entra en el primer commit queda en el historial para siempre, aunque lo borres después.

Paso 4 — Flujo de trabajo del día a día

La rutina de versionado es un ciclo corto que se repite en cada cambio:

1. Antes de tocar nada, asegúrate de que todo esté commiteado (git status limpio).
2. Haz la modificación en la configuración (ajusta una tasa, un drop, etc.).
3. Ve exactamente qué cambió con git diff.
4. Agrega y commitea con un mensaje descriptivo.

git diff                                   # revisa los cambios linea a linea
git add config_drops.ini
git commit -m "Aumenta tasa de drop de excellent para eventos de fin de semana"

La calidad del mensaje de commit determina la utilidad del historial. "ajustes" no ayuda a nadie; "Reduce EXP de 500x a 400x tras quejas de balanceo" cuenta una historia que entenderás meses después. Commitea cambios pequeños y cohesivos en vez de grandes paquetes: así, revertir uno no deshace los otros.

Paso 5 — Repositorio privado remoto

Un repositorio solo en tu máquina protege contra errores, pero no contra que la máquina se incendie. Envía el historial a un remoto privado.

git remote add origin [email protected]:tu-usuario/mu-config.git
git branch -M main
git push -u origin main

Insisto en el privado: las configuraciones revelan puertos, estructura interna y detalles que facilitan ataques, además de eventuales secretos que se escaparon del .gitignore. GitHub, GitLab y Bitbucket ofrecen repositorios privados gratuitos, no hay motivo para usar público aquí. Prefiere autenticación por clave SSH o token de acceso personal en vez de contraseña.

Paso 6 — Consultar el historial

El valor de Git aparece cuando necesitas entender el pasado.

git log --oneline --graph          # vista compacta de todos los commits
git log -p config_drops.ini        # historial completo de UN archivo
git show <hash>                    # detalle de un commit especifico
git blame config_exp.ini           # quien cambio cada linea y cuando

El git log -p <archivo> es especialmente útil en MU: ¿quieres saber cada vez que se tocó la tasa de EXP? Ese comando muestra cada modificación de ese archivo, con fecha y autor. El git blame responde "¿quién puso este valor aquí?" línea por línea.

Paso 7 — Revertir cambios con seguridad

Aquí está el pago de todo el esfuerzo. Existen varias formas de volver atrás, cada una para una situación.

Para producción, prefiere git revert a git reset --hard. El revert crea un commit nuevo que deshace el problemático, preservando el historial: todos ven que hubo una reversión y por qué. El reset --hard borra el historial posterior y, si ya fue enviado al remoto, causa conflictos para el equipo. Usa reset --hard solo en cambios locales que todavía no se compartieron.

Un ejemplo práctico: alteraste la tasa de drop, la publicaste, y la economía del servidor se descontroló. Para volver:

git log --oneline           # encuentra el hash del commit del cambio de drop
git revert a1b2c3d          # anula ese cambio especifico
git push                    # envia la reversion al remoto

Fíjate que deshiciste solo el cambio de drop, sin tocar nada más que se ajustó después. Eso es imposible con un backup de carpeta entera.

Buenas prácticas de mensajes y organización

• Escribe mensajes en imperativo y específicos: "Corrige puerto del ConnectServer", no "toqué las config".
• Commitea un cambio lógico a la vez; evita el commit "gigante" que mezcla diez ajustes distintos.
• Usa una branch separada para experimentos de balanceo y solo haz merge cuando esté validado.
• Marca versiones estables con tags (git tag -a v1.0 -m "Servidor estable post-apertura") para encontrarlas después.
• Revisa siempre con git diff y git status antes de commitear. La confirmación a ciegas es el origen de casi todo accidente con Git.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Git instalado y user.name/user.email configurados
• .gitignore creado ANTES del primer commit
• Base de datos, binarios y logs listados en el .gitignore
• Ninguna contraseña o cadena de conexión versionada
• Secretos extraídos a un archivo ignorado, con plantilla de ejemplo en el repo
• git status revisado antes de cada commit
• Primer commit hecho y verificado
• Repositorio remoto creado como PRIVADO
• Autenticación por clave SSH o token configurada
• Equipo alineado en usar revert en vez de reset --hard en lo compartido
• Mensajes de commit descriptivos convertidos en hábito
• Backup de la base de datos mantenido en rutina separada de Git

Versionar la configuración con Git transforma la administración del servidor de un ejercicio de memoria frágil en un proceso con historial completo y reversión precisa. La inversión es pequeña —media docena de comandos y el cuidado de mantener secretos y datos fuera del repositorio— y el retorno aparece la primera vez que necesitas deshacer un cambio sin perder todo lo que vino después. Empieza hoy versionando la carpeta de config, haz commits pequeños y frecuentes, y trata el .gitignore como tu línea de defensa contra fugas. Adapta los nombres de archivo a la realidad de tu emulador, porque esos detalles siempre varían por emulador/versión.

Preguntas frecuentes