A side road for one change

Think of it when you start a change that is not ready for everyone yet, or two people or agents work on the same code at once.

In everyday life

Two editors each take a photocopy of one chapter and mark it up for six weeks. Combining their copies at the end is slow, because both rewrote the same pages. Swapping marks every few days keeps each clash small.

One case

Two developers on a public library’s phone app each start a branch on 1 March. One reorganizes the loans screen; the other adds a holds list to the same screen. Neither merges until 12 April. By then 214 lines clash, and sorting them out takes 3 days.

A side road for one change
The ideaHow teams ship
A side road for one change

A separate line of commits where one change can grow without touching the main version. When the change is ready, you merge it: its commits join the main line.

How teams ship, Foundations

Every case

A branch lets a change be half finished in safety: the main version keeps working while you build. The cost comes at the merge. The longer a branch lives, the further it drifts from the main line, and the more of its lines clash with other people’s work. Each clash is a merge conflictTwo changes edit the same lines in different ways. The tool cannot pick one, so a person must decide., and a person must decide how to combine the two versions. Small, fresh clashes are easy; old ones need you to remember why both sides changed.

The word

Engineers call this

branch, mergeA separate line of commits where one change can grow without touching the main version. When the change is ready, you merge it: its commits join the main line.

Branch for one change, keep the branch short, and merge it within days. Bring the main line into your branch often, so clashes stay small.

Where this idea leads

Skills that encode it

  • principle-separate-before-serializing-shared-state pstackGive each actor its own owned file, key or branch, and merge only at the read or reporting boundary.
  • babysit-pr tstackKeeps an eye on changes to main, rebases when needed, and never merges a PR that is behind or has conflicts.
  • modernize tstackFor an old branch: inspects what landed on the base branch since the PR diverged, and looks beyond overlapping lines.