Branching Workflows for Teams

Git doesn't dictate how a team should use branches — that's a choice each team makes. A few well-known workflows have emerged, from the very simple to the very structured. Knowing them helps you fit into any team and pick the right one for your own projects.

GitHub Flow

The simplest common workflow, and a good default for web applications that are deployed continuously:

main     ●───────●─────────────●──────────●──────▶  always deployable
          \             /       \        /
feature    ●───●───●───●         ●──●───●
           (branch → PR → review → merge → deploy)

1. main is always in a releasable state.
2. Every change starts as a short-lived branch from main.
3. Open a pull request early; checks run and teammates review.
4. Merge to main once approved — and deploy soon after.

It's easy to learn and keeps everyone close to the latest code. It needs good automated tests, because there's no separate stabilisation stage.

Trunk-based development

Developers integrate into main (the "trunk") very frequently — at least daily — either by committing directly or through branches that live only a few hours. Unfinished features are hidden behind feature flags (switches in the code or configuration) rather than kept on long branches.

• Pros: very few merge conflicts, fast feedback, no "integration hell" at the end of a project.
• Needs: strong automated testing, continuous integration, and the discipline to keep every change small.

It's widely used by teams that deploy many times a day.

Git Flow

A structured model with several long-lived branches, designed for software released in numbered versions:

Git Flow suits products with scheduled releases and several supported versions, like desktop or mobile apps. For continuously deployed web apps it's usually more ceremony than needed, and its own author has suggested simpler workflows for such teams.

Release branches

A middle ground used by many projects: work flows into main (GitHub Flow style), and when a version is ready, a release/2.4 branch is cut from it. Bug fixes are made on main and cherry-picked to the release branches that need them (lesson 28), and each release is tagged (lesson 39).

Choosing

Conventions that matter more than the model

• Short-lived branches. The longer a branch lives, the harder it is to merge. Aim for days, not weeks.
• Small pull requests. Easier to review, quicker to merge, safer to revert.
• A protected main branch. Require reviews and passing checks, and block force pushes.
• Continuous integration. Automatically build and test every push and pull request (lesson 49).
• Consistent naming for branches and commit messages (lessons 10 and 22).
• An agreed merge style — merge commits, squash or rebase — so history looks the same throughout.
• Written down. Put the workflow in CONTRIBUTING.md so new teammates don't have to guess.

A hotfix in GitHub Flow

Production is broken and the fix is urgent. In GitHub Flow it's just a normal, very fast change:

git switch main
git pull
git switch -c fix/checkout-crash
# ...fix and test...
git commit -am "Fix crash when basket is empty at checkout"
git push -u origin fix/checkout-crash
gh pr create --fill

The PR gets a quick review, merges, and deploys. If you also maintain release branches, cherry-pick the fix onto them with git cherry-pick -x.

Try it yourself

Think about a project you work on (or would like to). Write a short CONTRIBUTING.md section describing its branching workflow: how branches are named, how long they live, how changes are reviewed and merged, and how releases are made.