Branching strategy

What it is

A branching strategy is the agreed convention a team uses to create, name, merge, and retire branches. It defines how long-lived or short-lived branches are, which branch is the source of truth, and how features flow into release.

Why it exists

Without a strategy, repositories devolve into a mess of conflicting branches, unmergeable work, and no clear “source of truth.” A strategy gives developers a repeatable path from feature to production while protecting the main line.

Key ideas

• Main/trunk — the single source of truth that always reflects deployable state.
• Short-lived feature branches — created from main, merged back quickly (trunk-based), keep merges small and conflicts rare.
• Long-lived branches — develop, release/*, hotfix/* (GitFlow), increase merge overhead the longer they live.
• Two dominant models:
  • Trunk-based development — everyone works on short branches off main and integrates continuously. Preferred for CD; fewer merge conflicts, faster feedback.
  • GitFlow — heavier model with main + develop + feature/release/hotfix branches. Suited to scheduled releases with versioning.

Exam notes

• Trunk-based pairs with continuous delivery; GitFlow pairs with planned, versioned releases.
• The longer a branch lives, the more likely it is to produce merge conflicts.
• Choose a strategy that matches the release cadence, not dogma.
• Protection rules (PR-required, branch policies) enforce the strategy at the platform level.

Related

git · pull-request · merge-conflict · semantic-versioning

📘 Source: Microsoft Learn — Branching Strategy