Branch & Merge
A branch does not copy commits. It is a label pointing at a single commit, so creating one costs nothing — and the line forks only once you move that label on its own. When the lines meet again, choosing between fast-forward, merge commit, squash and rebase is really choosing what shape to leave in the history, and that shape sets how hard it will be to undo later.
01Branch & Merge
Concept at a GlanceCommits stack up in a single line. Each one points at the commit before it, and that chain is the history.
A branch is a label, not a copy. Both main and feature merely point at one commit, so making one costs nothing.
Move one label on its own and the line forks. While commits pile up on feature, main stays where it was pointing.
If main never moved in the meantime, there is nothing to merge. Sliding the label forward is enough — that is a fast-forward.
If main moved too, you need a commit to join the two lines. Creating a new commit with two parents is a merge commit.
You can also fold the branch's commits into one. A squash leaves no fork, placing a single new commit on main.
Or you can rebuild the line entirely. A rebase rewrites the branch commits on top of the latest main, so the same content ends up with different hashes.
The same work leaves three different shapes: keep the fork, fold it into one point, or flatten it into a single line.
Reverting is where that difference shows. One point means one revert; a fork that stayed means naming which side to undo.
Leave a branch alone and main runs far ahead. Everything that diverged in between is a conflict candidate, so the cost of merging grows with time.
Cut the same work into short pieces and merge often, and the two meet before they have room to diverge. The variable that matters most is not the merge method but the branch's lifetime.
02 Understand It Simply
For EveryoneA branch is not a copy but a label pointing at one commit, which is why creating one costs nothing. A fork appears only when two labels point at different commits, and the merge method decides what the history keeps.
Commits chain backwards, each pointing at the one before it, and a branch is a name pointing at one link in that chain.
There are four ways to bring lines back together.
A fast-forward applies when no fork ever appeared: just slide the label forward.
A merge commit joins two lines with a new commit that has two parents.
A squash folds the branch's commits into a single new commit placed on the trunk.
A rebase rewrites the branch's commits on top of the latest trunk, flattening everything into one line — and because it creates new commits, identical content still gets different hashes.
Whichever you pick, the dominant variable is how long the branch lived: the longer it sits, the more of the trunk it has to reconcile with.
- –Choosing a PR merge method
- –shaping a history that is easy to revert
- –keeping branch lifetimes short before conflicts grow
- –and settling on squash or rebase as a team rule
03 Frequently Asked Questions
FAQWhat is Branch & Merge?+
A branch does not copy commits. It is a label pointing at a single commit, so creating one costs nothing — and the line forks only once you move that label on its own. When the lines meet again, choosing between fast-forward, merge commit, squash and rebase is really choosing what shape to leave in the history, and that shape sets how hard it will be to undo later.
Where is Branch & Merge used?+
Choosing a PR merge method, shaping a history that is easy to revert, keeping branch lifetimes short before conflicts grow, and settling on squash or rebase as a team rule.
What's a simple analogy for Branch & Merge?+
A branch is not a copy but a label pointing at one commit, which is why creating one costs nothing. A fork appears only when two labels point at different commits, and the merge method decides what the history keeps.