Merging a worktree back

Repository ▸ Integrate into Base… (⇧⌘M) merges a worktree’s branch into its base. The command names the base when it knows it — Integrate into main… — and so do the button in Review Changes and the worktree row’s menu, which integrate the work they show.

It never rebases the branch. The window that has the base checked out asks for the merge, and comes forward to do it; when nothing has the base checked out, Innesta says so instead.

The confirmation

It is the confirmation every merge gets, worked out without touching the working copy: the commits the merge brings, the files it writes, and the ones that would conflict. Open Diff… shows how the merge changes each file. A merge commit is made, or a squash when that is your default merge strategy; a branch whose work is already there says so.

Two things are particular to a worktree:

• What it has not committed stays where it is: the merge takes only the branch’s commits. The confirmation counts the uncommitted files and offers Open Worktree to Commit.
• Then remove the worktree decimal-numbers and delete its branch, checked for a merge commit, removes the worktree once the merge is done and deletes its branch, with a backup in Recovery. When the removal would have something to save, or something stands in its way, the removal sheet opens instead, to review first. It is not offered for a squash, which leaves its changes to commit, or for a merge expected to stop on conflicts.

If anything moves after the confirmation opened — the base, the branch, a new commit in the worktree — it opens again on what is there now, so the merge takes exactly what you saw.

Bringing the base in

Repository ▸ Update from Base… (⌃⇧⌘U) goes the other way, merging the base into the worktree’s branch, through the same confirmation, in the worktree’s window. The worktree has to be clean, unlocked and not in use by an agent that is working or waiting for you.