Commit Conventions
A fork that tracks an upstream engine accumulates a long history of changes from many sources. Being able to scan that history and tell an optimisation from a rendering feature from a backport is what makes future merges tractable.
Prefixes
Use one of the following at the start of the commit subject.
Prefix | Use for |
|---|---|
| Renderer work generally — the most used tag in the tree |
| New or changed rendering functionality specifically |
| Ray tracing |
| Forward renderer path |
| Performance work with no behaviour change |
| A change cherry-picked from a later engine version |
| Animation systems |
| Cameras, Character Movement, AI and the rest of the gameplay framework |
| The UObject memory subsystem |
| Data-oriented work, including ECS |
| Physics |
| Adding, updating or removing a plugin |
| Third-party library updates |
| Compiler, SDK and build environment |
| Changes to shipped engine defaults |
| Removing or gating cost from a default build |
| Mobile-specific work |
| VR-specific work |
| AMD-specific work |
| NVIDIA-specific work |
| Bug fixes |
Stacking prefixes
Most non-trivial changes carry more than one tag. Order them broad to specific, and put the backport marker last so the origin of the change reads at the end:
Adapted Backport rather than Backport signals that the upstream change did not apply cleanly and was rewritten against the Vite codebase. That distinction matters later, when someone is working out whether an upstream fix to the original commit also applies here.
Single-tag commits are fine when the change genuinely is one thing:
If a change spans genuinely unrelated areas, split it rather than stacking every tag in the table onto one commit.
Attribution
This is not a courtesy, it is a practical requirement. Without the link, nobody can determine what version was integrated, whether upstream has since fixed a bug in it, or whether the licence permits redistribution.
For backports of individual upstream commits, link the commit itself, not just the repository. See Backporting.
Commit body
The subject line says what changed. The body should say why, and what a reviewer needs to know:
What problem the change solves
Measured impact, for anything claiming to be an optimisation
Any console variable or compile-time switch added, with its default
Anything deliberately left undone
Measured impact matters. A commit prefixed [Optimization] with no numbers is an assertion, not a result. See Profiling for how to produce a credible before-and-after.
Branches
Rule | |
|---|---|
Work in progress goes on alternative branches | Do not push half-finished work to shared branches |
Note what remains | A brief comment on the branch or in the commit body |
Delete temporary branches | Once merged or abandoned |
Tell other forkers | So parallel effort is not wasted |
Console variables and switches
New console variables follow the engine's existing naming. Vite-specific ones are prefixed with the subsystem, then Vite:
Example | Subsystem |
|---|---|
| Renderer |
| Renderer |
| Physics |
Compile-time switches use the VITE_ prefix and must be defined with a default in Engine\Source\Runtime\Core\Public\Misc\CoreDefines.h:
Document any new switch in Compile-Time Switches in the same change. A switch that is not documented will be discovered by someone debugging a console variable that silently does nothing — which is exactly the failure mode VITE_RT_PSO_DEBLOAT caused before it was written up.