Merging Many Worktrees Into One Line

A free app I built myself. Give it a try.

The number of folders is the number of parallel jobs

In the first post a worktree was a tool for removing the cost of switching branches. The property that each folder is an independent build tree has a second use. Several folders can run at the same time without interfering with each other. Two processes building the same repository collide over output paths and break. With worktrees those paths are different to begin with.

So I use folders as work slots. A documentation worker sits in the docs folder and a feature worker in feature-login. Each runs builds and tests in their own place. The human only reviews, from the master folder.

It suits running several AI agents in parallel especially well. The agents never fight over file locks. When one breaks the build, the other slots are fine.

What was opened in parallel is collected in one line, not in merge commits

Merge five branches into master one at a time and the graph turns into a bundle of diamonds. Read that history later and you cannot tell which change was verified on top of which. So I go the other way. The branches go in order of descent. Each is appended onto the new tip of the previous one with rebase --onto. When that is done, every branch is fast-forwarded to the final tip.

My --gw1 flag does this. The plan it prints before running looks like this.

merge plan — linearize 3 worktrees onto 'master', then ff-all:
  master               pull --ff-only: already up to date
  master               (base, tip ce5b697f)
  docs                 ff-advance chain to be09cdb1
  feature/login        rebase --onto <docs> ce5b697f
  then fast-forward every branch (incl. master) to the final tip
  then push master → origin/master (fast-forward, never forced)

The result is one straight line with no merge commits. Every worktree points at the same commit, so a build in any folder gives the same result.

* 8494e3f add login page
* be09cdb write docs
* ce5b697 init

The value of the automation comes from atomicity

A rebase chain that hits a conflict halfway stops with half of the history rewritten. That state is the biggest risk in the whole thing. So on failure every branch is put back to the sha it had on entry. I built two conflicting branches and actually ran it. All that was left was the line below and exit 1. The shas of all three branches were identical to what they had been.

git-worktree: rebase conflict on 'feature/login' (onto previous tip) — rolled back
to entry state (except the origin ff of 'master'). resolve 'feature/login' manually,
then retry.

Because the rollback is guaranteed, I do not guess at the outcome with a dry run. I just run it and see. A three-way conflict only shows up when a rebase is actually attempted, so this is the faster route. How each stage handles failure is decided in advance.

The sync goes first because stacking on a stale base means diverging again at push time. At the other end, rolling back a failed push would throw away a linear result you worked for. A network or permission problem should not cost you that. So there the tool leaves git's own refusal message and a retry command. Failure is signalled through the exit code alone. Fix the cause, run it again, and only the push is retried.

Summary

Worktree folders are parallel work slots, and the price of adding slots is paid at the final merge. Pay that price as one rebase chain rather than a bundle of merge commits. The history stays readable, and every folder starts again from the same commit. Whether a job can be handed to automation is decided by atomicity on failure, not by speed.

Next time you run three or more branches at once, write the script that will combine them first. Put the rollback in that script.