Git de servidor FiveM: o que fazer commit, .gitignore e deploys com git pull

Um servidor que vive apenas em um disco não tem histórico: uma edição ruim em uma noite de sexta não pode ser desfeita, e mover máquinas significa copiar pastas manualmente. Colocá-lo sob git corrige ambas. Este guia mostra o que fazer commit, o .gitignore a usar, como manter segredos fora, e como depliar com git pull.

#O que vai no repositório

Faça commit das coisas que você escreve ou configura:

• Seus recursos (a pasta resources/, incluindo configuração e arquivos SQL).
• Um server.cfg sem segredos.
• Arquivos pequenos de ajudante, como um README com a ordem de inicialização.

Não faça commit de arquivos gerados ou privados:

• cache/, que FiveM reconstrói. Veja clear the FiveM cache.
• A pasta de dados do txAdmin (txData), com suas configurações, contas de admin e logs.
• Segredos: a chave de licença, senha de banco de dados e chaves de API.
• Logs, crash dumps e node_modules.

#Um .gitignore inicial

Na raiz do repositório (a pasta de dados do servidor que contém resources/ e server.cfg):

cache/
txData/
*.log
*.dmp
node_modules/
secrets.cfg
.env

Se você versionou a pasta txAdmin inteira de propósito, remova txData/ da lista, mas mantenha-a privada e fora de qualquer repositório compartilhado. Ativos binários grandes (carros em streaming, MLOs) tornam um repositório grande; considere se devem estar em git de jeito nenhum, ou mantidos em um armazenamento separado.

#Mantenha chaves fora de server.cfg

Esta é a parte que dá errado na maioria das vezes. Estas linhas são segredos:

sv_licenseKey cfxk_xxxxxxxxxxxx
set mysql_connection_string "mysql://user:password@localhost/fivem"
set steam_webApiKey "xxxxxxxx"
rcon_password "xxxxxxxx"

Mova-os para um arquivo separado, secrets.cfg, que está em .gitignore:

# secrets.cfg  (never committed)
sv_licenseKey cfxk_xxxxxxxxxxxx
set mysql_connection_string "mysql://user:password@localhost/fivem"
set steam_webApiKey "xxxxxxxx"

E carregue-o no topo do server.cfg commitado:

exec secrets.cfg

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
sv_hostname "My Server"

ensure oxmysql
ensure ox_lib

Faça commit de um secrets.cfg.example com valores vazios para que a próxima pessoa saiba o que preencher. Veja server.cfg explained para as configurações em si.

Atenção: se uma chave foi commitada alguma vez, deletá-la em um commit posterior não é suficiente. Ainda está no histórico. Gere uma nova chave ou senha e trate a antiga como vazada.

#Crie o repositório

cd /path/to/server-data
git init
git add .
git status

Leia a lista de git status antes de fazer commit e verifique que nada da lista "não fazer commit" está preparado. Depois:

git commit -m "Initial server"
git branch -M main
git remote add origin [email protected]:youruser/your-server.git
git push -u origin main

Use um repositório privado. Scripts pagos são licenciados para você, e colocá-los em um repositório público é redistribuição, mesmo que o código esteja criptografado. Veja escrow lack entitlement para como ativos criptografados estão ligados à sua conta.

#Deploy com git pull

Na máquina que executa o servidor, clone uma vez e puxe depois:

git clone [email protected]:youruser/your-server.git server-data
cd server-data
# create secrets.cfg on this machine (not from git)

Para atualizar após um push de seu PC de desenvolvimento:

cd server-data
git pull

Depois recarregue o que mudou. Para um único recurso, do console do servidor:

refresh
restart my_resource

Se server.cfg ou uma ordem de inicialização mudou, agende um reinício completo (veja scheduled restarts). Não faça git pull no meio das horas de pico sem um plano, já que muitos recursos reiniciando ao mesmo tempo podem fazer o servidor pico.

Para autenticação em um repositório privado, use uma chave de deploy SSH com acesso apenas leitura, ou um token de acesso pessoal. Nunca digite sua própria senha em scripts.

#Um hábito de branch simples

Mantenha main como o que está ao vivo. Faça mudanças em uma branch, teste em um servidor local ou de staging, depois faça merge:

git checkout -b new-police-job
# edit, test
git commit -am "Add police job"
git checkout main
git merge new-police-job
git push

Quando algo quebra após um pull, git log mostra o que mudou e git revert <commit> o desfaz sem perder histórico. Git não é um backup do banco de dados, porém: mantenha backups reais também, como em backup your FiveM server.

#Lista de verificação