Git en servidor FiveM: qué hacer commit, .gitignore y despliegues con git pull

Un servidor que vive solo en un disco no tiene historial: una mala edición en una noche de viernes no puede ser deshecha, y mover máquinas significa copiar carpetas a mano. Ponerlo bajo git arregla ambos. Esta guía muestra qué hacer commit, el .gitignore a usar, cómo mantener secretos fuera, y cómo desplegar con git pull.

#Qué va en el repositorio

Haz commit de las cosas que escribes o configuras:

• Tus recursos (la carpeta resources/, incluyendo configuración y archivos SQL).
• Un server.cfg sin secretos.
• Pequeños archivos auxiliares, como un README con el orden de inicio.

No hagas commit de archivos generados o privados:

• cache/, que FiveM reconstruye. Ver limpiar el caché de FiveM.
• La carpeta de datos de txAdmin (txData), con sus configuraciones, cuentas de admin y registros.
• Secretos: la clave de licencia, contraseña de base de datos y claves API.
• Registros, volcados de crash y node_modules.

#Un .gitignore inicial

En la raíz del repositorio (la carpeta de datos del servidor que contiene resources/ y server.cfg):

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

Si versionas la carpeta txAdmin completa a propósito, elimina txData/ de la lista, pero mantenla privada y fuera de cualquier repositorio compartido. Los grandes activos binarios (autos transmitidos, MLOs) hacen un repositorio grande; considera si deberían estar en git en absoluto, o mantenidos en una tienda separada.

#Mantén las claves fuera de server.cfg

Esta es la parte que usualmente va mal. Estas líneas son secretos:

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

Muévelas a un archivo separado, secrets.cfg, que está en .gitignore:

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

Y cárgalo en la parte superior del server.cfg comprometido:

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

Haz commit de un secrets.cfg.example con valores vacíos para que la siguiente persona sepa qué rellenar. Ver server.cfg explicado para los ajustes en sí.

Cuidado: si una clave fue comprometida alguna vez, eliminarla en un commit posterior no es suficiente. Aún está en el historial. Genera una nueva clave o contraseña y trata la antigua como filtrada.

#Crea el repositorio

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

Lee la lista de git status antes de hacer commit y comprueba que nada de la lista "no hacer commit" esté staged. Luego:

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

Usa un repositorio privado. Los recursos pagos son licenciados para ti, y ponerlos en un repositorio público es redistribución, incluso si el código está encriptado. Ver falta de derechos de escrow para cómo los activos encriptados están vinculados a tu cuenta.

#Despliega con git pull

En la máquina que ejecuta el servidor, clona una vez y luego extrae:

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

Para actualizar después de un push desde tu PC de desarrollo:

cd server-data
git pull

Luego recarga lo que cambió. Para un solo recurso, desde la consola del servidor:

refresh
restart my_resource

Si server.cfg o un orden de inicio cambió, programa un reinicio completo (ver reinicios programados). No hagas git pull en medio de horas pico sin un plan, ya que muchos recursos reiniciando a la vez pueden pico el servidor.

Para la autenticación en un repositorio privado, usa una clave de despliegue SSH con acceso de solo lectura, o un token de acceso personal. Nunca escribas tu propia contraseña en scripts.

#Un hábito de rama simple

Mantén main como lo que está en vivo. Haz cambios en una rama, prueba en un servidor local o de prueba, luego fusiona:

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

Cuando algo se rompe después de un pull, git log muestra lo que cambió y git revert <commit> lo deshace sin perder historial. Git no es una copia de seguridad de la base de datos, aunque: mantén copias de seguridad reales también, como en respalda tu servidor FiveM.

#Checklist