FiveM server git: co commitować, .gitignore i wdrażanie git pull

Serwer, który żyje tylko na jednym dysku, nie ma historii: zła edycja w piątkowy wieczór nie może być cofnięta i przenoszenie maszyn oznacza kopiowanie folderów ręcznie. Umieszczenie pod git to naprawia. Ten przewodnik pokazuje co commitować, .gitignore do użycia, jak trzymać tajemnice poza oraz jak wdrażać z git pull.

#Co idzie do repozytorium

Commituj rzeczy, które piszesz lub konfigurujesz:

• Twoje zasoby (folder resources/, łącznie z konfigiem i plikami SQL).
• A server.cfg bez tajemnic.
• Małe pliki pomocnicze, takie jak README z porządkiem uruchamiania.

Nie commituj wygenerowanych lub prywatnych plików:

• cache/, które FiveM przebudowuje. Zajrzyj clear the FiveM cache.
• Folder danych txAdmin (txData), z jego ustawieniami, kontami admina i logami.
• Tajemnice: klucz licencji, hasło bazy danych i klucze API.
• Logi, zrzuty awarii i node_modules.

#Początkowy .gitignore

W katalogu głównym repozytorium (folder danych serwera zawierający resources/ i server.cfg):

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

Jeśli wersjonujesz cały folder txAdmin na pościel, usuń txData/ z listy, ale trzymaj go prywatnym i poza każdym wspólnym repozytorium. Duże binarne zasoby (streamowane samochody, MLO) robią repozytorium dużym; zastanów się, czy powinny być w git w ogóle, czy trzymane w osobnym magazynie.

#Trzymaj klucze poza server.cfg

To jest część, która idzie źle najczęściej. Te linie są tajemnicami:

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

Przenieś je do osobnego pliku, secrets.cfg, który jest w .gitignore:

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

I załaduj go na szczycie commitowanego server.cfg:

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

Commituj secrets.cfg.example z pustymi wartościami, aby następna osoba wiedziała co wypełnić. Zajrzyj server.cfg explained dla samych ustawień.

Ostrzeżenie: jeśli klucz kiedykolwiek był commitowany, usuwanie go w późniejszym commicie nie wystarczy. Wciąż jest w historii. Wygeneruj nowy klucz lub hasło i traktuj stare jako przeciek.

#Utwórz repozytorium

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

Przeczytaj listę git status przed commitowaniem i sprawdzaj, że nic z listy "do not commit" nie jest staged. Następnie:

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

Używaj prywatnego repozytorium. Płatne zasoby są licencjonowane dla Ciebie, a umieszczenie ich w publicznym repozytorium to redystrybuacja, nawet jeśli kod jest zaszyfrowany. Zajrzyj escrow lack entitlement dla tego, jak zaszyfrowane zasoby są związane z Twoim kontem.

#Wdrażanie z git pull

Na maszynie, która uruchamia serwer, klonuj raz i pull potem:

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

Aby zaktualizować po pularze z Twojego komputera Development:

cd server-data
git pull

Następnie przeładuj, co się zmieniło. Dla pojedynczego zasobu z konsoli serwera:

refresh
restart my_resource

Jeśli server.cfg lub porządek uruchamiania się zmienił, zaplanuj pełny restart (zobacz scheduled restarts). Nie rób git pull w środku godzin szczytu bez planu, ponieważ wiele zasobów restartujących naraz może podnieść serwer.

Dla uwierzytelniania w prywatnym repozytorium, używaj klucza wdrażania SSH z dostępem tylko do odczytu, lub tokenu dostępu osobistego. Nigdy nie wpisuj swojego własnego hasła do skryptów.

#Prosty zwyczaj gałęzi

Trzymaj main jako to co jest na żywo. Rób zmiany na gałęzi, testuj na lokalnym lub staging serwerze, następnie scalaj:

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

Gdy coś się psuje po pull, git log pokazuje co się zmieniło i git revert <commit> cofa to bez utraty historii. Git nie jest kopią zapasową bazy danych, jednak: trzymaj rzeczywiste kopie zapasowe też, jak w backup your FiveM server.

#Checklist