Git branching strategies: trunk, release branches and integration cost
Choose Git branches around integration speed and supported release lines. Compare trunk-based development, release branches and Gitflow with a worked hotfix example.
TL;DR: Keep integration frequent. Use short-lived branches when one current service version is deployed continuously; add release branches when customers genuinely need independent supported versions. A branch creates another line of change that somebody must reconcile.
The decision starts with what you ship
A web service deployed by one team and an agent installed on thousands of customer laptops have different release problems. The service can usually move all customers onto the next build. The agent may need security fixes on versions 4.2 and 4.3 while version 5 is under development. That support commitment justifies release branches.
For the service, start with one protected main branch, changes small enough to review within a day, required checks and frequent merges. In trunk-based development, developers can commit through short-lived review branches; the defining property is frequent integration into the shared trunk. Incomplete product work can sit behind a flag, provided the disabled path is tested and the flag has an owner and removal date.
Git supplies the graph operations. Your team supplies the rules for which commits may become production artifacts. The Git branching-workflows chapter describes long-running and topic branches; it does not make a particular workflow mandatory.
Compare the ongoing work
| Strategy | Fits this constraint | Work you must budget for |
|---|---|---|
| Short-lived branches into trunk | One current deployable product line | Fast reviews, reliable checks, small changes and feature isolation |
| Trunk plus release branches | Multiple versions supported simultaneously | Backports, branch-specific tests and explicit end-of-support dates |
| Gitflow-style develop/release/hotfix branches | A team already operating coordinated release trains | More integration points and a clear rule for where fixes flow |
| Long-lived team branches | Temporary isolation of unusually disruptive work | Frequent upstream integration and a scheduled return to shared development |
A release calendar alone rarely requires a separate develop branch. You can build release candidates from main and promote a selected artifact when the release window opens. Conversely, renaming a month-old feature branch “short-lived” does nothing to reduce its integration risk.
A fix that must reach two releases
Assume main is preparing version 5, and customers still use 4.2. The following graph is illustrative. A backported change has a different commit identity even when its intent matches the mainline fix.
Fix the defect on the appropriate active line, then explicitly track which supported lines need it. If the emergency fix starts on the release branch, create a corresponding mainline change before closing the incident. If it starts on main, backport only the necessary change. A large merge from main may bring an incompatible database client into a maintenance release.
Record the original change in the backport description, even if conflict resolution changes the patch. Run the release branch's tests. Passing against version 5 dependencies does not establish compatibility with 4.2. Once 4.2 support ends, archive that branch under the repository policy so it stops appearing to be a supported delivery path.
Protect integration, then measure whether it works
A required check should run on the revision that will actually enter the branch. Two changes can each pass against yesterday's main and fail when combined. A merge queue or a fresh integration check helps detect that interaction. Sensitive changes still need an accountable reviewer; a green status alone does not establish that the design is appropriate.
Measure branch age, review waiting time, integration failures and escaped changes that required recovery. Use those observations to fix the bottleneck. A team with a five-day review queue cannot sustain one-day branches by adding a policy sentence. Assign review coverage and split changes so the next person can understand them.
Production records should connect a deployment to a source revision and an immutable artifact. Avoid deploying “whatever is on the release branch” without recording the resolved commit. Branches move. See artifact promotion for the distinction between selecting source and selecting tested bytes.
For a busy protected trunk, consider merge queues and required checks. The queue tests a candidate containing the current base and earlier queued changes, which addresses combinations that independent PR checks can miss.
An interview answer with a boundary
For a team delivering an internal payments API several times a day, choose protected trunk with short-lived review branches and feature flags for incomplete behavior. Keep a release branch only if an actual consumer must remain on a separately patched API or deployment version. Explain how you will verify compatibility before removing the old path.
For a packaged product with two supported customer versions, choose trunk plus two bounded maintenance branches. State the cost: every relevant fix needs a backport decision, independent checks and a release record. Gitflow may be workable in an established organization, but name the coordination requirement that pays for its extra branches.
Work through the failure
A developer fixes a production defect on release/4.2. Two weeks later the same defect returns in version 5. What failed?
The release process lacked a verified forward-port to the active development line. Repair the process with an explicit list of supported branches on the fix, linked follow-up changes, and a closure condition that checks each required destination. Merely asking developers to remember main leaves the same failure possible.
Practice the concrete choice in trunk-based development and short-lived branches, then study merge versus rebase to explain what happens to the graph.