Git del server FiveM: cosa fare commit, .gitignore e deploy git pull

Un server che vive solo su un disco non ha storia: una modifica sbagliata venerdì sera non può essere annullata, e spostare macchine significa copiare cartelle a mano. Metterlo sotto git risolve entrambi. Questa guida mostra cosa fare commit, il .gitignore da usare, come tenere i segreti fuori, e come distribuire con git pull.

#Cosa va nel repository

Fai commit delle cose che scrivi o configuri:

• Le tue risorse (la cartella resources/, inclusi config e file SQL).
• Un server.cfg senza segreti.
• Piccoli file helper, come un README con l'ordine di avvio.

Non fare commit di file generati o privati:

• cache/, che FiveM ricostruisce. Vedi pulisci la cache FiveM.
• La cartella dati txAdmin (txData), con le sue impostazioni, account admin e log.
• Segreti: la chiave di licenza, la password del database e le chiavi API.
• Log, crash dump e node_modules.

#Un .gitignore iniziale

Alla radice del repository (la cartella dei dati del server che contiene resources/ e server.cfg):

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

Se versioni l'intera cartella txAdmin di proposito, rimuovi txData/ dall'elenco, ma mantienila privata e fuori da qualsiasi repository condiviso. I grandi asset binari (auto trasmesse, MLO) rendono un repository grande; considera se dovrebbero essere in git, o mantenuti in un negozio separato.

#Tieni le chiavi fuori da server.cfg

Questa è la parte che di solito va male. Queste righe sono segreti:

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

Spostali in un file separato, secrets.cfg, che è in .gitignore:

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

E caricalo all'inizio del server.cfg committato:

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

Fai commit di un secrets.cfg.example con valori vuoti in modo che la persona successiva sappia cosa riempire. Vedi server.cfg spiegato per le impostazioni stesse.

Attenzione: se una chiave è mai stata committata, eliminarla in un commit successivo non è sufficiente. È ancora nella cronologia. Genera una nuova chiave o password e tratta quella vecchia come trapelata.

#Crea il repository

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

Leggi l'elenco git status prima di fare commit e controlla che nulla dall'elenco "do not commit" sia staged. Poi:

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 repository privato. Le risorse pagate sono autorizzate a te, e metterle in un repository pubblico è redistribuzione, anche se il codice è crittografato. Vedi escrow lack entitlement per come gli asset crittografati sono legati al tuo account.

#Distribuisci con git pull

Sulla macchina che esegue il server, clona una volta e tira dopo:

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

Per aggiornare dopo un push dal tuo PC di sviluppo:

cd server-data
git pull

Poi ricaricare quello che è cambiato. Per una singola risorsa, dalla console del server:

refresh
restart my_resource

Se server.cfg o un ordine di avvio è cambiato, programma un riavvio completo (vedi riavvii programmati). Non fare git pull nel mezzo delle ore di punta senza un piano, poiché molte risorse che riavviano contemporaneamente possono causare un picco del server.

Per l'autenticazione su un repository privato, usa una chiave di distribuzione SSH con accesso di sola lettura, o un token di accesso personale. Non digitare mai la tua password nei script.

#Un semplice abito di ramo

Mantieni main come ciò che è live. Fai modifiche su un ramo, testa su un server locale o di staging, poi 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 qualcosa si rompe dopo un pull, git log mostra cosa è cambiato e git revert <commit> lo annulla senza perdere la cronologia. Git non è un backup del database, però: mantieni backup reali anche, come in backup del tuo server FiveM.

#Elenco di controllo