Update a Git-managed FiveM resource while preserving local settings
Blindly replacing a Git-managed resource can erase local settings or leave a mixture of old and new files. Prepare the update on your own administrator workstation or an authorised development environment, then upload a complete reviewed release. This guide does not require a root shell on the game node or permission to run Git inside the game container.
Record the current resource
Write down the upstream repository, installed release or commit, resource folder name and local configuration files. Download a private copy of the deployed directory, including files ignored by Git. Record whether the release requires generated web assets, dependencies or a database migration.
A repository history is not a complete operational backup. Credentials and runtime data should normally remain outside public source control, while ignored files may contain exactly the settings you need to recover. Do not upload your deployment folder to a public repository to make this update easier.
Inspect changes locally
- Open the local repository used for development. Run
git status --shortto identify tracked edits and untracked files. The Git status reference describes these categories. - Review
git diffandgit diff --cachedprivately. These inspect different sets of changes; check both before assuming the working copy matches the installed release. - Preserve local settings in an external private backup and a reviewed development branch where appropriate. Never commit passwords simply to obtain a clean working tree.
- Obtain the target release from the resource's authorised upstream project. Compare its release notes and file changes with the installed revision using your Git client's comparison view. The official diff documentation explains comparison output.
- Reapply only intentional local changes to the target copy. Merge configuration by meaning rather than replacing a new schema with the entire old file. Keep a note of each retained customisation.
Package and test the target release
Test the prepared directory on an isolated service with a separate database. Confirm startup, the resource's main action and persistence after reconnecting. If a migration is required, test it on a copied database first and confirm the author's downgrade limitations. A code revert cannot automatically undo altered tables.
Deploy and retain recovery copies
Schedule a production window and take a fresh consistent checkpoint. Stop the affected service as its framework requires, deploy the complete prepared release and repeat your acceptance checks. Avoid leaving another active copy of the resource in an automatically started folder.
If checks fail, stop further writes and use the matching pre-update code, configuration and database recovery plan. Do not run destructive Git reset or clean commands against the live deployment. Keep the old private package, target revision and test record until the update is accepted and your backup retention policy allows cleanup.