Git serveur FiveM : quoi committer, .gitignore et déploiements git pull

Un serveur qui vit seulement sur un disque n'a pas d'historique : une mauvaise édition un vendredi soir ne peut pas être annulée, et déplacer les machines signifie copier les dossiers à la main. Le mettre sous git corrige les deux. Ce guide montre quoi committer, le .gitignore à utiliser, comment garder les secrets en dehors, et comment déployer avec git pull.

#Qu'est-ce qui va dans le dépôt

Commitez les choses que vous écrivez ou configurez :

• Vos ressources (le dossier resources/, y compris config et fichiers SQL).
• Un server.cfg sans secrets.
• Petits fichiers d'aide, comme un README avec l'ordre de démarrage.

Ne commitez pas les fichiers générés ou privés :

• cache/, que FiveM reconstruit. Consultez effacer le cache FiveM.
• Le dossier de données txAdmin (txData), avec ses paramètres, comptes admin et journaux.
• Secrets : la clé de licence, mot de passe de base de données et clés API.
• Journaux, vidages de crash et node_modules.

#Un .gitignore de démarrage

À la racine du dépôt (le dossier de données du serveur qui contient resources/ et server.cfg) :

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

Si vous versionnez le dossier txAdmin entier exprès, supprimez txData/ de la liste, mais gardez-le privé et en dehors de tout dépôt partagé. Les gros actifs binaires (voitures diffusées, MLOs) rendent un dépôt gros ; réfléchissez à si elles devraient être dans git du tout, ou conservées dans un magasin séparé.

#Garder les clés en dehors du server.cfg

C'est la partie qui se trompe le plus souvent. Ces lignes sont des secrets :

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

Déplacez-les dans un fichier séparé, secrets.cfg, qui est dans .gitignore :

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

Et chargez-le au début du server.cfg commité :

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

Commitez un secrets.cfg.example avec des valeurs vides pour que la prochaine personne sache quoi remplir. Consultez server.cfg expliqué pour les paramètres eux-mêmes.

Attention : si une clé a jamais été committée, la supprimer dans un commit ultérieur ne suffit pas. Elle est toujours dans l'historique. Générez une nouvelle clé ou un nouveau mot de passe et traitez l'ancien comme fuité.

#Créer le dépôt

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

Lisez la liste git status avant de committer et vérifiez que rien de la liste « do not commit » n'est préparé. Ensuite :

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

Utilisez un dépôt privé. Les ressources payantes vous sont autorisées, et les mettre dans un dépôt public c'est redistribution, même si le code est chiffré. Consultez escrow lack entitlement pour comment les actifs chiffrés sont liés à votre compte.

#Déployer avec git pull

Sur la machine qui exécute le serveur, clonez une fois et tirez après :

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

Pour mettre à jour après un push de votre PC de développement :

cd server-data
git pull

Puis recharger ce qui a changé. Pour une seule ressource, depuis la console du serveur :

refresh
restart my_resource

Si server.cfg ou un ordre de démarrage a changé, planifiez un redémarrage complet (consultez redémarrages planifiés). Ne faites pas git pull au milieu des heures de pointe sans plan, car de nombreuses ressources redémarrant à la fois peuvent faire monter le serveur.

Pour l'authentification sur un dépôt privé, utilisez une clé de déploiement SSH avec accès lecture uniquement, ou un jeton d'accès personnel. Ne tapez jamais votre propre mot de passe dans des scripts.

#Une simple habitude de branche

Gardez main comme ce qui est en direct. Faites des changements sur une branche, testez sur un serveur local ou de staging, puis fusionnez :

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

Quand quelque chose se casse après un pull, git log montre ce qui a changé et git revert <commit> l'annule sans perdre l'historique. Git n'est pas une sauvegarde de la base de données, cependant : gardez de vraies sauvegardes aussi, comme dans sauvegarde votre serveur FiveM.

#Liste de contrôle