Do you use Git or GitHub for version control? Yes. RAX Development uses Git for every serious FiveM project and hosts work in private GitHub repositories (or your org's GitHub/GitLab if you prefer). That means every script change, config tweak, and hotfix is tracked, reviewable, and reversible — not lost in a random resources_backup_final_v3 folder.
Quick answer: Git tracks what changed and when; GitHub stores the repo, branches, and collaboration. We never commit secrets (DB passwords, Tebex keys, webhook URLs). Pair Git with automated backups and staging. Hire a fivem dev
Why version control matters on FiveM
- Rollback — Bad script update? Revert to last known-good commit instead of guessing which file broke the server
- History — See who changed economy values, anticheat config, or job payouts
- Staging — Test on a branch or staging server before touching live players
- Handoff — New dev or staff lead can clone the repo instead of FTP chaos
- Accountability — Clear commits when paired with staff logging
Git does not replace full server backups (database, player data, uploaded assets). Use both. See our automated backup guide.
Git vs GitHub (plain English)
| Tool | Role on FiveM projects |
|---|---|
| Git | Local version control: commits, branches, merges, tags (e.g. v1.0-launch) |
| GitHub | Remote hosting, private repos, pull requests, issues, optional Actions for checks |
We can also work with GitLab or Bitbucket if your community already standardizes on them. The workflow is the same; GitHub is our default for client visibility and access control.
What we put in the repository
- Custom and configured resources (Lua, JS, HTML UI where applicable)
- server.cfg templates (secrets injected via environment or local-only files)
- Framework config exports (sanitized — no live DB passwords)
- Documentation: install steps, dependency list, launch checklist
- SQL migrations or schema files for repeatable database setup
What we never commit
- MySQL/MariaDB passwords and connection strings with live credentials
- Tebex secret keys, Discord bot tokens, webhook URLs
- License keys for paid escrow resources (often not allowed by sellers anyway)
- Player databases or
cache/ runtime folders - Leaked or pirated Tebex assets
A proper .gitignore excludes node_modules, build artifacts, logs, and machine-specific paths. For monetization secrets see Tebex setup and database security.
Typical branch workflow
- main (or
production) — matches what runs on the live server after deploy - develop / staging — integration branch tested on a staging FXServer
- feature/* — One branch per feature (new job, anticheat tweak, MLO script hookup)
- hotfix/* — Emergency fix merged back to main and develop
- Tag releases — Mark launch day and major updates for easy rollback
Smaller customization jobs may use a single branch with tagged releases; full server builds use the full workflow above.
Deploying from Git to your FXServer
- git pull on the VPS (or deploy script) after you approve changes
- Restart only affected resources when possible; full restart when framework/core changes
- Run database migrations in a maintenance window
- Smoke-test on staging first — especially after artifact updates
txAdmin can coexist with Git: txAdmin for restarts and monitoring, Git for source of truth. Do not rely on txAdmin file backups alone for code history.
Client access and ownership
- Private repo under RAX or transferred to your GitHub organization
- You can get read or write access depending on contract and technical comfort
- Custom scripts you paid for can be handed off with repo access per agreement
- Escrow Tebex resources stay installed on the server; they are not copied into public repos
Git vs “just edit on the VPS”
Editing live files over SFTP or txAdmin File Manager works for tiny tweaks but fails at scale:
- No diff when something breaks at 2 AM
- Two devs overwrite each other's changes
- Hard to reproduce staging from production
- Risky during peak player hours
Professional custom scripts and dev standby assume Git is in place or we set it up on day one.
How RAX Development helps
- Initialize Git + private GitHub for new server builds
- Migrate messy FTP servers into a clean repo structure
- Write
.gitignore, README, and deploy notes for your staff - Branch strategy for staging vs production
- Coordinate with backups, Tebex, and security hardening
US Navy Veteran, 13 years IT. Reviews · Shop · Contact
Related: Local vs VPS / txAdmin · Automated backups · Launch timeline · Before starting a community
Conclusion
Do you use Git or GitHub for version control? Yes — Git for history and rollbacks, GitHub (or your host) for private collaboration, with secrets kept out of the repo. RAX Development sets up version control on server builds and ongoing dev work so your FiveM project stays maintainable.
Start with Git workflow
Git setup included on server builds. Custom repos and migration quoted.
Script packages Server build