Choosing a branching strategy

A branching strategy is a coordination rule, not just a list of branch names. Choose one based on release frequency, team size, test automation and how long unfinished changes can safely stay isolated. Whatever you choose, define a protected integration branch, review policy and method for tracing what was deployed.

Compare common strategies

Strategy	Core idea	Best fit	Important trade-off
Short-lived feature branches / GitHub Flow	Branch from main, review, merge and deploy	Small teams, continuous delivery	Long-running branches accumulate conflicts
Trunk-based development	Very small changes integrated frequently	Teams with rapid tests and feature flags	Requires discipline to keep incomplete features disabled
GitFlow	Long-lived development and release branches	Multiple supported releases or constrained release schedules	Extra merges, coordination and maintenance overhead

Default recommendation: small, short-lived branches merged through pull requests to a protected main. Do not introduce a complicated branch hierarchy unless your release requirements justify it. A team that ships a live game every week may choose different gates than one maintaining several long-lived customer versions.

Use feature flags for incomplete work

A feature branch protects the integration history from unreviewed code. It does not solve every problem caused by weeks of divergence. For features that require many small steps, consider merging tested infrastructure behind a disabled feature flag. The branch can stay short-lived while the player-facing behavior remains turned off until it is ready.

Binary assets and game teams

Git is excellent for text assets such as C#, C++, Markdown and build configuration. Large binary art files are harder to merge. Use Git LFS where appropriate and document any locking or storage limits; for projects that depend on Perforce for large game assets, document which files are authoritative in each system. Do not store the same asset as separately editable sources in both Git and Perforce without an agreed synchronization policy.

Rules worth writing down

A branching strategy and an integration method are separate choices. Compare merge commits, squash and rebase before setting the team’s merge policy.

Choose branch naming, how commits reference issues, required test suites, how fast reviews should happen, whether squash merging is standard, when release tags are created and how to perform a rollback. A strategy becomes healthy when anyone on the team can safely follow it, not when the Git graph looks impressive.

Related: feature branching, issue-to-release and Git workflows.

Branch naming: main is an example. Use master or your repository’s actual default branch where applicable. See Git terminology.