Contribute to the upstream documentation
A correction to this independent site and a contribution to Cfx.re are separate changes. Use this project’s contribution guide for FiveM Docs. For official material, follow the Cfx.re contribution policy at the reviewed revision and recheck the policy before opening a pull request.
Choose the repository and scope
Use citizenfx/fivem-docs for the official manuals. Native-description changes belong to citizenfx/natives; platform implementation work belongs to citizenfx/fivem. A link to an external generated catalog does not mean its data lives in the Markdown documentation repository.
For a small correction, the GitHub file editor can propose an isolated change. For a larger change, fork the intended repository, clone your fork and create a topic branch. The fork is your writable origin; the official repository is a read-only comparison remote named upstream. Inspect git remote -v before pushing so you know which repository will change.
A manual-page change should state the problem, its source evidence, the exact artifact or game track affected, and how the example was checked. Keep unrelated rewrites out of the same pull request. Link the relevant issue, and complete the target repository’s pull-request template. A successful website build verifies rendering; it does not establish that a native executed in the game.
Apply the official writing and media conventions
| Area | Official convention in the reviewed policy |
|---|---|
| Page structure | Put the title in frontmatter; use descriptive ## sections and ### subsections. |
| Lists | Use dashes for unordered items and incrementing numbers for ordered procedures. |
| Language | Use clear imperative instructions, consistent terms, American English and complete punctuation. Explain prerequisites for new readers. |
| Code | Use language-tagged fences, spaces rather than tabs, and explicit context before or after the example. Prefer Lua examples, with corresponding JavaScript/C# versions where applicable. |
| Links | Use descriptive Markdown links. Official internal routes start with /docs/, omit .md and use a trailing slash before a fragment. Do not paste this site’s different route scheme into the official repository. |
| Native references | Use the official site’s native_link shortcode with the native’s exact identifier. Hugo shortcodes are not interchangeable with this site’s MDX components. |
| Images | Store images under static/, provide meaningful alt text and put the image near the relevant explanation. Prefer WebP, otherwise PNG; GIF is suitable for short animation. |
| Image filenames | Tutorial media uses lowercase hyphenated names. Game-reference media preserves the exact entry’s original casing, underscores and numbers. |
| Alerts | Use the alert shortcode syntax demonstrated in the target repository, not an invented JSX callout. |
The official policy permits AI tools only for spelling, grammar and clarity improvements; it does not permit fully AI-generated articles or guides as upstream submissions. Do not submit an independently generated guide as an original upstream article under that policy. This page describes the contribution process; it does not submit content, assert upstream acceptance, or replace that policy with this project’s rules.
Create an isolated branch
The following example assumes you have already cloned your own fork, have a clean worktree, and have confirmed that the official default branch is still master. Inspect remotes before adding one; do not run remote add repeatedly on an existing setup.
# Inspect before changing anything.
git status --short
git remote -v
# Add only when this remote is absent.
git remote add upstream https://github.com/citizenfx/fivem-docs.git
git fetch upstream
git switch -c docs/clarify-client-setup upstream/master
# Edit the intended page, then inspect and stage only that page.
git diff --check
git diff
git add content/docs/client-manual/installing-fivem.md
git diff --cached
git commit -m "docs: clarify client setup prerequisites"
git push -u origin docs/clarify-client-setupThe filename and branch name are examples, not a request to edit that particular manual. Select the file that actually needs a correction. Do not use git add . when the checkout may contain unrelated changes, credentials, captures or generated files.
Rebase an existing proposal
Read the official rebase guide . A rebase rewrites the topic branch’s commits on top of a newer base. It is not a routine operation for the shared default branch.
Before rebasing, finish or safely save uncommitted work, verify that you are on your topic branch, and create a local backup branch. Fetch the remotes and inspect both the base changes and any new remote commits. Coordinate first when another person also writes to the branch.
git switch docs/clarify-client-setup
git status --short
git branch backup/client-setup-before-rebase
git fetch upstream
git fetch origin
git rebase upstream/masterFor a conflict, open the affected file, preserve the intended changes from both sides, remove conflict markers, stage the resolved file and run git rebase --continue. Repeat as necessary. git rebase --abort restores the pre-rebase state when the resolution is not ready. Do not blindly skip a commit to make the command succeed.
Run the relevant validation again and review the rewritten diff. Updating your own previously published topic branch requires a history-replacement push; use --force-with-lease, never an unconditional --force. The lease is a safeguard, not proof that overwriting is appropriate. Fetch and reconcile any collaborator’s work first; a background fetch can update the tracking ref used by a default lease. An explicit expected remote SHA provides a stronger, deliberate lease when coordinating a shared proposal.
Squash related commits
The official squash guide describes combining related work into one reviewable commit. Create a backup first and inspect which commits belong to the topic branch. Do not count commits from the default branch or another person’s work into the squash range.
An interactive rebase from the verified merge base is usually easier to review than guessing HEAD~N. Keep the first relevant commit as pick, mark later related commits squash or fixup, and write a message that describes the resulting change. squash combines messages; fixup discards the later message. Resolve conflicts as above, inspect the final diff and rerun tests before updating the branch with an appropriate lease.
Squashing is not necessary merely to hide an intermediate mistake. The reviewer needs the final coherent change and trustworthy validation. Never rewrite the shared upstream history as part of a documentation contribution.
Before opening or updating the pull request
Verify links, code fences, image paths, native names, execution side, error handling and version-dependent statements. Preserve source dates on archived material. Include exact test commands and state anything that was not executed. Check that the PR targets the intended upstream branch and contains no unrelated files. The upstream maintainer decides acceptance; a successful push or a green check is not approval.