Como versionar a configuração do seu servidor de MU Online com Git

Todo administrador de servidor de MU Online já viveu esta cena: o servidor estava perfeito ontem, alguém ajustou um valor de drop, mexeu numa taxa de experiência ou trocou uma linha de configuração do GameServer, e hoje algo quebrou — mas ninguém lembra exatamente o que mudou. Sem um registro de alterações, a única saída é caçar o problema no escuro, comparando arquivos de memória ou restaurando um backup inteiro e perdendo tudo que veio depois. Versionar a configuração com Git resolve esse problema na raiz. Git é um sistema de controle de versão que guarda o histórico completo de cada arquivo de texto: quem mudou, quando, o que exatamente foi alterado, e permite voltar a qualquer ponto anterior com precisão cirúrgica. Para um servidor de MU, onde dezenas de arquivos .ini, .txt e .dat de configuração governam o comportamento do jogo, isso é ouro. Este tutorial mostra por que versionar, o que colocar no repositório e — igualmente importante — o que jamais colocar, como configurar um .gitignore adequado, como usar repositório privado e como reverter mudanças com confiança. Os nomes e formatos de arquivo citados são exemplos e variam por emulador/versão, mas o método é universal.

Por que versionar a configuração

Versionar não é frescura de programador. Para um servidor de MU, entrega benefícios concretos:

• Rastreabilidade: cada mudança fica registrada com autor, data e descrição. Você sabe exatamente quando a taxa de experiência foi alterada e por quê.
• Reversão precisa: em vez de restaurar um backup inteiro, você desfaz apenas a mudança problemática, preservando todo o resto.
• Comparação (diff): antes de aplicar, você vê linha por linha o que vai mudar. Isso pega erros de digitação e valores absurdos antes que cheguem ao ar.
• Colaboração segura: se sua equipe tem mais de um administrador, o Git evita que um sobrescreva o trabalho do outro sem perceber.
• Documentação viva: o histórico de commits vira um diário do servidor, contando a evolução das decisões de balanceamento.

Sem versionamento, a "memória" do servidor vive na cabeça de quem administra — e some quando essa pessoa esquece ou sai. Com Git, a memória é do projeto.

Pré-requisitos

• Git instalado na máquina (baixe de git-scm.com; no Windows vem com o Git Bash, útil também).
• Acesso à pasta do servidor onde ficam os arquivos de configuração.
• Uma conta em um provedor de repositório privado (GitHub, GitLab ou Bitbucket) — todos oferecem repositórios privados gratuitos.
• Noções mínimas de linha de comando (abrir um terminal na pasta e digitar comandos).
• Editor de texto para criar o arquivo .gitignore.

Não é preciso saber programar. O conjunto de comandos usados aqui é pequeno e repetitivo. Se você já configurou um servidor seguindo um guia de como criar servidor de MU Online, a curva do Git será tranquila.

O que versionar e o que NÃO versionar

Esta é a decisão mais importante do processo. Colocar a coisa errada no Git causa desde repositórios inchados até vazamento de dados.

A regra mental: Git é para configuração de texto que muda por decisão humana, não para dados operacionais que mudam sozinhos. O banco de dados é o exemplo clássico do que não versionar — ele muda a cada login, a cada item dropado, a cada segundo de jogo. Tentar versionar isso enche o repositório de ruído e ainda coloca dados sensíveis de contas sob risco. O banco tem seu próprio ciclo de backup no SQL Server, separado do Git.

Binários também ficam de fora por outro motivo: Git é otimizado para texto. Ele guarda diffs eficientes de arquivos de texto, mas trata cada versão de um .exe como um blob inteiro novo, inchando o repositório rapidamente. Se você precisa versionar binários grandes, existem extensões específicas para isso, mas para configuração pura elas são desnecessárias.

Passo 1 — Inicializar o repositório

Abra um terminal na pasta de configuração do servidor. O ideal é versionar uma pasta que contenha os arquivos de config, e não a raiz inteira com binários.

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

O git init cria um subdiretório oculto .git que guardará todo o histórico. A partir daqui, aquela pasta é um repositório. As duas linhas de config identificam quem faz os commits — importante quando há mais de um administrador.

Passo 2 — Criar o .gitignore ANTES do primeiro commit

Este passo vem antes de adicionar qualquer arquivo, e é deliberado. O .gitignore é uma lista de padrões que o Git deve ignorar. Criá-lo primeiro impede que você commite acidentalmente algo sensível já no início.

# Banco de dados - NUNCA versionar
*.mdf
*.ldf
*.bak
*.bacpac

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

# Logs
*.log
logs/
Logs/

# Segredos e credenciais
*secret*
*.key
connection.config
credentials.ini

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

Ajuste os padrões à estrutura do seu emulador. Se as senhas de conexão com o banco vivem dentro de um arquivo de config que você precisa versionar, a solução é extrair o segredo para um arquivo separado (ignorado) e manter no repositório apenas um modelo de exemplo, como connection.example.ini, sem a senha real. Varia por emulador/versão onde as credenciais ficam armazenadas.

Passo 3 — Primeiro commit

Com o .gitignore no lugar, adicione os arquivos e faça o commit inicial.

git add .
git status        # confira o que sera commitado ANTES de confirmar
git commit -m "Configuracao inicial do servidor"

O git status antes do commit é um hábito de ouro. Ele lista tudo que entrará no commit. Pare e leia essa lista. Se aparecer algum .mdf, .log ou arquivo com senha, seu .gitignore está incompleto — corrija antes de confirmar. Um segredo que entra no primeiro commit fica no histórico para sempre, mesmo que você o apague depois.

Passo 4 — Fluxo de trabalho no dia a dia

A rotina de versionamento é um ciclo curto que se repete a cada mudança:

1. Antes de mexer, garanta que está tudo commitado (git status limpo).
2. Faça a alteração na configuração (ajuste uma taxa, um drop, etc.).
3. Veja exatamente o que mudou com git diff.
4. Adicione e commite com uma mensagem descritiva.

git diff                                   # revise as mudancas linha a linha
git add config_drops.ini
git commit -m "Aumenta taxa de drop de excellent para eventos de fim de semana"

A qualidade da mensagem de commit determina a utilidade do histórico. "ajustes" não ajuda ninguém; "Reduz EXP de 500x para 400x apos reclamacoes de balanceamento" conta uma história que você entenderá meses depois. Commite mudanças pequenas e coesas em vez de grandes pacotes — assim, reverter uma delas não desfaz as outras.

Passo 5 — Repositório privado remoto

Um repositório só na sua máquina protege contra erros, mas não contra a máquina pegar fogo. Envie o histórico para um remoto privado.

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

Insisto no privado: as configurações revelam portas, estrutura interna e detalhes que facilitam ataques, além de eventuais segredos que escaparam do .gitignore. GitHub, GitLab e Bitbucket oferecem repositórios privados gratuitos — não há motivo para usar público aqui. Prefira autenticação por chave SSH ou token de acesso pessoal em vez de senha.

Passo 6 — Consultar o histórico

O valor do Git aparece quando você precisa entender o passado.

git log --oneline --graph          # visao compacta de todos os commits
git log -p config_drops.ini        # historico completo de UM arquivo
git show <hash>                    # detalhe de um commit especifico
git blame config_exp.ini           # quem mudou cada linha e quando

O git log -p <arquivo> é especialmente útil no MU: quer saber toda vez que a taxa de EXP foi mexida? Esse comando mostra cada alteração daquele arquivo, com data e autor. O git blame responde "quem colocou esse valor aqui?" linha por linha.

Passo 7 — Reverter mudanças com segurança

Aqui está o pagamento de todo o esforço. Existem várias formas de voltar atrás, cada uma para uma situação.

Para produção, prefira git revert a git reset --hard. O revert cria um commit novo que desfaz o problemático, preservando o histórico — todo mundo enxerga que houve uma reversão e por quê. O reset --hard apaga o histórico posterior e, se já foi enviado ao remoto, causa conflitos para a equipe. Use reset --hard apenas em mudanças locais que ainda não foram compartilhadas.

Um exemplo prático: você alterou a taxa de drop, publicou, e a economia do servidor desandou. Para voltar:

git log --oneline           # encontre o hash do commit da mudanca de drop
git revert a1b2c3d          # anula aquela mudanca especifica
git push                    # envia a reversao ao remoto

Repare que você desfez só a mudança de drop, sem tocar em nada mais que foi ajustado depois. Isso é impossível com um backup de pasta inteira.

Boas práticas de mensagens e organização

• Escreva mensagens no imperativo e específicas: "Corrige porta do ConnectServer", não "mexi nas config".
• Commite uma mudança lógica por vez; evite o commit "gigante" que mistura dez ajustes diferentes.
• Use uma branch separada para experimentos de balanceamento e só faça merge quando validado.
• Marque versões estáveis com tags (git tag -a v1.0 -m "Servidor estavel pos-abertura") para achá-las depois.
• Revise sempre com git diff e git status antes de commitar. Confirmação cega é a origem de quase todo acidente com Git.

Erros comuns e soluções

Checklist de lançamento

• Git instalado e user.name/user.email configurados
• .gitignore criado ANTES do primeiro commit
• Banco de dados, binários e logs listados no .gitignore
• Nenhuma senha ou string de conexão versionada
• Segredos extraídos para arquivo ignorado, com modelo de exemplo no repo
• git status revisado antes de cada commit
• Primeiro commit feito e conferido
• Repositório remoto criado como PRIVADO
• Autenticação por chave SSH ou token configurada
• Equipe alinhada em usar revert em vez de reset --hard no compartilhado
• Mensagens de commit descritivas viraram hábito
• Backup do banco de dados mantido em rotina separada do Git

Versionar a configuração com Git transforma a administração do servidor de um exercício de memória frágil em um processo com histórico completo e reversão precisa. O investimento é pequeno — meia dúzia de comandos e o cuidado de manter segredos e dados fora do repositório — e o retorno aparece na primeira vez que você precisa desfazer uma mudança sem perder tudo o que veio depois. Comece hoje versionando a pasta de config, faça commits pequenos e frequentes, e trate o .gitignore como sua linha de defesa contra vazamentos. Adapte os nomes de arquivo à realidade do seu emulador, porque esses detalhes sempre variam por emulador/versão.

Perguntas frequentes