Why a branching workflow?
A branching workflow is a team's contract for how code goes from idea to production: which branches exist, what is protected, how releases and hotfixes happen. Four axes — branch count, branch lifetime, release cadence, integration timing — separate the three models.
Five engineers, one repository, and no agreement on how branches work. Two people push directly to main; one keeps a three-week feature branch that has silently drifted from everyone else; nobody knows which commit is in production right now, and a hotfix for a paying customer just got accidentally bundled with a half-finished redesign. Nothing here is a git bug. It is the absence of a workflow — a shared rule for how code moves from idea to production.
By the end of this lesson you will be able to say what a branching workflow actually decides for a team, and name the four axes that separate the three models — git-flow, GitHub flow, and trunk-based development — that the rest of this unit compares head to head.
After this lesson you can define a branching workflow as a team contract, list the four axes that distinguish workflows (number of long-lived branches, branch lifetime, release cadence, integration timing), and explain the failure modes that appear when a team has no workflow at all.
A branching workflow is the team’s agreed contract for how code travels from idea to production. It answers a fixed set of questions, the same way for everyone: which branches always exist, which branch is the source of truth, who is allowed to push where, how a change gets reviewed and integrated, how a release is cut, and how an urgent production fix bypasses the normal path. Git itself is unopinionated — it gives you cheap branches and merges and stays silent about how you should use them. The workflow is the policy layer a team adds on top so that two engineers, on two different days, make the same structural decision without a meeting.
Without a workflow you get four recurring failure modes. They are predictable enough to name:
- No release point. If everyone commits to
mainad hoc, nobody can answer “what is in production?” becausemainmay contain half-finished work. - Merge hell. Long branches that live for weeks diverge so far that re-integrating them is a multi-hour conflict-resolution session.
- Broken shared branch. With nothing protected, one bad push breaks the build for the whole team.
- Hotfixes tangled with features. With no separate path for urgent fixes, a one-line security patch ships only by dragging unfinished work along with it.
A workflow exists precisely to make each of these impossible by structure, not by everyone remembering to be careful.
Four axes distinguish every workflow you will meet. When you compare git-flow, GitHub flow, and trunk-based development, you are really comparing four dials:
- Number of long-lived branches. A long-lived branch is one that is never deleted and accumulates history forever (
main, sometimesdevelop). One? Two? The count is the single biggest structural difference. - Branch lifetime of working branches. Do feature branches live for hours, days, or weeks before merging?
- Release cadence. Do you deploy continuously on every merge, or cut versioned releases (1.4.0, 1.5.0) on a schedule?
- Integration timing. Do you integrate work into the shared line continuously (many times a day) or in big batches at the end?
Every workflow in this unit is just a specific setting of these four dials, chosen to fit a specific kind of team and release model.
▸Why this works
Why does the number of long-lived branches dominate? Because long-lived branches are where divergence accumulates. Each one is a separate timeline that must eventually be reconciled with the others, and reconciliation cost grows with how long and how far they drift. A workflow with one long-lived branch (GitHub flow, trunk-based) structurally minimises divergence; one with several (git-flow: main plus develop, plus release branches) buys flexibility for versioned releases at the cost of constant cross-branch merging. Almost every tradeoff in this unit traces back to that single dial.
A protected branch is how the contract is enforced, not just documented. A protected branch is one the platform (GitHub, GitLab) refuses to let anyone push to directly: changes must arrive through a pull/merge request that passes required CI checks and reviews. This is what turns a workflow from a wiki page nobody reads into a rule the tooling enforces. Protecting main is the one piece of every workflow in this unit that is non-negotiable — it is what guarantees the source-of-truth branch is always reviewed and always green.
Diagnosing a team in trouble.
A six-person product team complains that “git is a mess.” You ask four questions — the four axes. Their answers: long-lived branches? Just main, but it is not protected, so anyone pushes anything. Branch lifetime? One engineer has a feature branch open for 19 days. Release cadence? They deploy main whenever someone feels like it. Integration timing? Big-bang — the 19-day branch will land all at once next week.
Nothing about git is broken. The diagnosis falls straight out of the axes: an unprotected main (broken-build risk), one runaway long-lived branch (merge-hell risk), and no defined release point (nobody knows what is live). The fix is not a git command — it is adopting a workflow: protect main, cap branch lifetime to a day or two, and define “merge to main = deploy.” That is essentially GitHub flow, which the next lessons build up to.
▸Common mistake
A common mistake is treating “we use git” as if it were a workflow. Git is the tool; the workflow is the agreement about how to use it. Two teams can both “use git” and have completely incompatible rules — one cuts versioned release branches, the other deploys every merge. When onboarding, the question that matters is never “do you use git” but “which branches are long-lived, what is protected, and what does merging to the main line trigger.” If a team cannot answer those, they have a tool but no workflow.
Which of these is the single axis that most structurally separates the three workflows in this unit?
A branching workflow is a team’s agreed contract for how code moves from idea to review to production — which branches exist, what is protected, how releases are cut, and how hotfixes happen. Without one you hit four predictable failures: no release point, merge hell, a broken shared branch, and hotfixes tangled with features. Every workflow is a setting of four dials: number of long-lived branches, branch lifetime, release cadence, and integration timing, and the long-lived-branch count dominates the rest. Next you will meet the heaviest of the three models — git-flow — and see exactly why all those long-lived branches both help and hurt.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.