version-control-workflowlisted

# Version Control Workflow ## Purpose Version control on a software project is well-trodden. On a *game* project it is not: repositories contain gigabytes of binary assets that cannot be merged, and engine projects generate files that must be committed and files that must never be. Getting this wrong produces destroyed work, repositories too large to clone, and merges that silently lose a day of level design. ## When to use - Setting up a repository for an engine project. - When merges repeatedly lose work, or conflicts in scenes and prefabs are routine. - When the repository has become slow to clone or fetch. - When deciding whether a generated file belongs in version control. - Before onboarding contributors to a project with binary assets. ## When NOT to use - Release tagging and shipping process. Use `release-management`. - Build and test automation. Use `ci-cd-pipelines`. - Ordinary text-only projects with an established convention — follow the project's convention rather than importing another. ## Required context | Fact | Why it matters | |---|---| | Engine and project type | Determines what is generated and what must be committed | | Whether binary assets are involved | Decides whether LFS and locking are needed | | Team size and concurrency | Decides how much branch isolation costs versus buys | | Existing branching convention | Do not introduce a second one | | Whether artists and designers use the repository | Non-programmers need a workflow that does not