Branch

When a team had only one copy of the code, everybody else waited while one person edited it. Two people opening the same file meant whoever saved last wiped out the earlier edit, so the first question before touching anything was "is anyone in the payment code right now?"

Schedules ended up governed by turn-taking rather than by headcount. At Pagedeck, while Theo spent a third day on the checkout screen, fixing a single typo in a button label meant waiting for him to finish. Anyone unwilling to wait copied the whole folder onto their own machine, which meant later comparing two versions by eye and merging them by hand — and any line missed in that comparison simply vanished.

A branch is the device that removes the waiting. The difference from hand-managed copies is that the tooling absorbs the bookkeeping. Because version control remembers where each line of work split off and how the main line moved since then, nobody has to lay two files side by side to put them back together.

Creating a branch doesn't copy the code. It adds one more label pointing at a single point in the history that already exists. That's why making a branch takes under a second and costs almost no storage.

The point a label aims at is a commit — a set of changes recorded as one lump, with a message saying what changed and why. The space those commits accumulate in is a repository, and a branch is the name attached to one chain of commits inside it. Git, the effective standard for tracking change history, works this way.

A branch's life runs through four stages.

1. Splitting off. A new name is created pointing at the last commit on the main line. Teams usually split from a trunk called main into something like payment-retry.
2. Stacking. Commits land on top of that name. Each one moves only your label forward and leaves the main line's label alone, so you can stack twelve commits and nothing changes on the screen of someone looking at the trunk.
3. Catching up. Meanwhile other people's commits pile up on the main line too. The further back your split point falls, the more lines will disagree later, so you pull the main line's changes into your branch every few days.
4. Merging. A merge brings both lines of change together. If the two sides edited the same line of the same file differently, the tool declines to decide and flags a merge conflict for a person to resolve.

The amount of disagreement tracks the time spent apart. A branch merged after one day overlaps on two or three lines and takes minutes. A branch left for three weeks can have ten files out of alignment, and sorting that out means rereading changes other people made weeks ago to work out which version should survive.

Switching branches rewrites the files on your machine to match the one you moved to, and coming back restores your edits untouched.

Branches attach one per piece of work. One feature, one bug, one experiment each gets its own, and once the work lands on the main line the branch is deleted. The two Theo created this week were feature/payment-retry and fix/login-typo, and both were gone the day after they merged.

That's also why names aren't arbitrary. With thirty branches open, the name is the only clue to what each one contains, so most teams settle on a convention of a prefix plus a ticket number.

Branches are also where a human gets inserted before anything merges. A pull request is the request to merge your branch into the main line, and the code review is the process of a colleague reading the changed lines on that screen and leaving comments. Blocking the main line until someone approves is the default setting, which makes a branch a queue waiting for inspection as much as a place to work.

How many branches a team keeps, and for how long, is a team agreement. Trunk-based development keeps branches under two days and merges to the main line several times a day. It forces collisions before they grow, which only holds up with dense automated checks. Git flow goes the other way, keeping separate branches for development, releases, and urgent fixes, with movement allowed only along fixed paths. It suits products that bundle versions for a scheduled date, but the branches live long enough that merging costs real time.

"Did you edit that straight on main? Put it on a branch and open it again."

Editing the trunk directly makes the change hard to review and hard to undo, so split a separate line of work.

"That branch has been open two weeks. Pull main into it."

It split off long enough ago that disagreements have piled up, so take the trunk's latest changes first.

"There are three features in one branch and I can't review it."

Unrelated work is mixed into a single line, so there's no way to tell which change belongs to what.

The week this structure paid off at Pagedeck was the one spent on payment retries. Theo was halfway through that feature when Grace spotted a wrong price on the signup screen and asked for an immediate fix. The copy change was ten lines; the payment feature didn't work yet.

Because the two sat on different branches, Theo merged the copy fix into the main line that afternoon and kept building payments at the original pace. With a single copy, the options would have been shipping half-built payment code alongside the fix, or leaving the wrong price up until payments were finished.

The most common assumption is that opening a branch keeps the work safe. It looks that way, since the code on your branch stays exactly as you left it no matter what happens to the trunk. But surviving and staying usable are different things. While the main line moves forward, the ground your code stands on gets older, and a branch parked for two months takes days to merge — or reaches the point where discarding it and starting over is faster.

The other frequent belief is that lots of branches make a repository heavy. The word sounds like a copy, so it seems volume should grow with the count. A branch is a label pointing at one commit, so the count costs almost nothing. What costs something is lifespan. Getting this backwards leads people to ration branches exactly when they need one, piling several tasks into one line and producing a lump nobody can review or unwind.