Stop 04 · Git & Version ControlTopics · 2/8

Branching Strategies (Git Flow, Trunk-Based)

In short

Ten people pushing to one repo need rules, or main breaks every day. Your team's branching strategy decides how often code merges and how releases happen.

Different team conventions for organizing branches — Git Flow uses long-lived feature/release branches, trunk-based development favors short-lived branches merged frequently into a single main branch.

The mascot sits at a library table with friends, adding small pages to one shared folder.

Think of it like this

The group project report

One way: each friend writes a whole chapter alone for three weeks, then you merge everything the night before submission. Painful. Another way: everyone adds a page to the shared doc every day and fixes clashes while they're small. That's Git Flow versus trunk-based.

Watch it happen

Two ways to branch

Git Flow

develop, feature, release, hotfix branches
Features merge after days or weeks
Fits scheduled, versioned releases

Trunk-based

Short branches off main only
Merge at least daily, behind feature flags
Fits continuous delivery

Most teams doing CI/CD lean trunk-based. Git Flow still suits apps with planned version releases, like mobile apps or packaged software.

The big ideas

What you need to know

Short-lived branches

The longer a branch lives, the more it drifts from main and the harder the merge. Aim for hours or a day or two.

Feature flags

Merge unfinished work hidden behind a flag. The code is in main but users don't see it until you switch it on.

Protect main

Require pull requests and passing CI before anything lands on main, whatever strategy you choose.

Tags mark releases

git tag v1.4.0 marks the exact commit you shipped, so you can rebuild or roll back to it.

See it in code

Walk through the code

bash

1# Trunk-based: small branch, merged quickly2git switch main && git pull3git switch -c fix/login-timeout4# ...edit, commit...5git push -u origin fix/login-timeout6# open a PR, CI passes, merge the same day7 8# Mark a release9git tag -a v1.4.0 -m "Release 1.4.0"10git push origin v1.4.0

1/3Start from the latest main and create a short branch named after the change.

git switch -c creates and moves to a new branch. It's the newer, clearer version of git checkout -b.

Save yourself the pain

Common mistakes

Oops

Keeping a feature branch alive for a month, then facing 200 conflicts.

Do this instead

Split the work into small pieces and merge often. Hide unfinished parts behind a feature flag.

Oops

Copying Git Flow because a blog said so, for a web app deployed ten times a day.

Do this instead

Pick the strategy that matches how you release. Continuous deployment and long-lived release branches fight each other.

Your mission

Try both styles

~30 min

Quick check

Your team deploys to production many times a day. Which branching approach fits best?

Go deeper

1Compare Git Flow and trunk-based development for a hypothetical team's release cadence.
2Learn why trunk-based development pairs naturally with strong CI/CD practices (Phase 6).
3Understand there's no single 'correct' strategy — it depends on team size and release frequency.