Development Operations

git branching strategies

1. Trunk-Based Development

Everyone integrates into a single main branch (often main or master), with very short-lived branches (or direct commits) and frequent integration.

When to Use:
  • Small–medium teams practicing continuous integration and frequent releases.
  • Products where keeping main always releasable is a goal.
  • Teams investing in tests and automation.
Pros:
  • Simple mental model; single source of truth.
  • Encourages small, frequent commits, reducing merge conflicts.
  • Works well with CI/CD and continuous delivery.
Cons:
  • Requires strong test automation; broken trunk affects everyone.
  • Large/risky changes need extra techniques like feature flags.
  • Unfamiliar for teams used to long-lived branches.

2. Feature Branching

Each feature, bug, or issue gets its own branch from a base (often develop or main) and merges back after completion.

When to Use:
  • Teams wanting clear isolation and PR-based reviews.
  • Medium–large teams with parallel work.
  • When branches are short-lived and merged frequently.
Pros:
  • Isolates work; broken code doesn’t affect mainline.
  • Easy mapping between branches and work items.
  • Supports parallel development without overlap.
Cons:
  • Long-lived branches can drift.
  • May lead to big-bang merges and integration pain.
  • Encourages large, infrequent commits.

3. GitFlow

Structured branching with long-lived main and develop branches, and short-lived feature, release, and hotfix branches.

When to Use:
  • Large projects with formal release cycles.
  • Organizations needing strict controls and versioning.
  • Environments requiring hotfix separation.
Pros:
  • Clear release lifecycle and version management.
  • Supports parallel development and maintenance.
  • Enforces strong release discipline.
Cons:
  • Complex; many branches and rules to manage.
  • Slows down fast-moving teams.
  • Overkill for small teams or simple services.

4. Release Branching

Each release or major version has its own branch; ongoing development continues elsewhere.

When to Use:
  • Products supporting multiple old versions.
  • Teams with long-lived or patch release cycles.
  • When a code freeze per release is needed.
Pros:
  • Allows release stabilization and patching.
  • Clear boundaries between versions.
  • Supports maintenance of multiple releases.
Cons:
  • Extra maintenance overhead.
  • Cherry-picking fixes can be tedious.
  • Potential for divergence between branches.

5. Environment Branching

Maintains long-lived branches for each environment (dev, test, stage, prod) with changes flowing through them.

When to Use:
  • Legacy setups tied to environment-specific branches.
  • As a temporary structure during migration to CI/CD.
Pros:
  • Clear mapping between branch and environment.
  • Easy for non-developers to understand.
Cons:
  • High risk of environment drift.
  • Merges can become confusing and error-prone.
  • Incompatible with modern deployment practices.

6. GitHub Flow

main is always deployable. Create short-lived branches, open pull requests, merge frequently, and deploy continuously.

When to Use:
  • Web or SaaS products deploying frequently.
  • Small–medium teams with good automation and monitoring.
Pros:
  • Simple and lightweight workflow.
  • Ideal for continuous deployment.
  • Pairs well with feature flags and monitoring.
Cons:
  • No structure for long-lived or multiple versions.
  • Requires robust testing and quick rollback options.

7. Choosing a Strategy

A quick mapping for context-based decisions:

  • Max speed and simplicity: Trunk-based or GitHub Flow.
  • Strict release/version control: GitFlow + release branches.
  • Feature isolation and PR workflow: Feature branching (on trunk or develop).
  • Multiple supported versions: Release branching layered on GitFlow.