Skip to content
Optimal Lab

DevOps · interactive

Branching strategies

Three developers work for two weeks. The longer their work stays on separate branches, the further it drifts from everyone else's, and the more painful merging gets. Numbers are illustrative.

main
Ana
Ben
Cy
day 0day 10
Merges to main
29
Conflicting lines per merge
~12
Idea → main
~1 days

Small changes merge every day behind feature flags. Each merge is tiny, so conflicts are rare and easy, and main is always close to what's deployed.

Strategy

Step 2 of 4

  1. 1

    Branches drift

    Every day apart, both sides change the same code more. Conflicts grow faster than linearly.

    “Merge hell”.

  2. 2

    Trunk-based development

    Merge small changes to main at least daily. Unfinished features hide behind flags.

    Needs good tests and fast CI.

  3. 3

    Short-lived feature branches

    A branch per change, reviewed in a PR, merged within a day or two.

    GitHub flow.

  4. 4

    Release branches only if you must

    Mobile apps or on-prem software may need maintained release lines. Web services rarely do.

    GitFlow suits shipped versions, not SaaS.

In production

Tools and technologies

How a team branches shapes how fast it ships.

Not tied to one language — use these names when you search docs or design a system.