Merged Is Relative To Where It Merged

When changes are stacked on top of each other, the word "merged" stops meaning what everyone assumes it means. A merge request can be genuinely, correctly merged and still be nowhere near the branch you ship from. It went into its neighbour, the neighbour is still waiting for review, and the status in the tracker is green. So before approving anything in a stack, ask one question first: merged into what? Everything else in the review depends on the answer.

Why stacks make this easy to get wrong

Stacking is a perfectly sensible way to work. A large piece of functionality is too big to review in one sitting, so it is cut into a sequence of small changes, each built on the one before it. The first sets up the foundation, the second adds a capability on top, the third uses both. Each is reviewable in minutes rather than hours, and reviewers get to say yes to something small instead of skimming something enormous.

The cost is that each change in the stack points at a different target. The bottom one targets trunk. The next one targets the branch of the one below it. The one above that targets that branch, and so on. The platform is doing exactly what it should: showing the difference between a change and the thing it was built against. That keeps the diff small and readable. It also means the merge button on any given change is perfectly happy to merge into the wrong place, because from the platform's point of view there is no wrong place. It is just a branch.

I've come to treat that as a design property of stacks rather than a user error to be scolded away. The moment a tool lets you merge a change into a branch that is not the delivery branch, a human will occasionally do it, usually at the end of a long day, usually with a sensible-looking target already selected. Recently I saw exactly that: a change in a dependent chain was merged into a sibling's branch instead of the main line, and the corrective work then had to be reviewed in its own right. Nobody did anything unreasonable. The interface simply made the wrong merge look identical to the right one.

What the badge doesn't tell you

A merged badge answers a narrow question: has this branch been folded into its target? It does not answer the question people actually care about, which is whether this behaviour will be in the next release. Those only coincide when the target is trunk.

The danger is quiet, which is what makes it expensive. The code is not lost. The history looks tidy. The ticket gets closed because the linked request says merged. Weeks later someone asks why the feature does not behave as described, and the investigation starts from the assumption that it shipped, which is the one assumption nobody checks. In effect the badge has produced a small false confirmation, and every later decision quietly leans on it.

This is the same family of mistake as trusting a green pipeline without asking what it covered, and as trusting a fix without confirming it runs where the failure occurs. The tool reports a true statement, and the team hears a bigger one.

Reviewing a stack well

The first habit I would adopt is to review in dependency order, from the bottom up, and to confirm the target branch of each change before reading a line of the diff. If the target is not what the stack's plan says it should be, stop there. A beautifully reviewed change aimed at the wrong branch is wasted effort, because the review will have to be repeated once the target is corrected and the diff changes shape.

The second is to be deliberate about when a lower change merges. If the bottom of the stack merges into trunk, the changes above it should be retargeted to trunk before they merge, not after. Otherwise they carry the old parent branch with them, and the history now contains a branch that is both merged and not. Many teams settle on merging the whole stack in order, in one sitting, by one person who is responsible for the sequence. That sounds bureaucratic until you have untangled the alternative.

The third is to verify the outcome rather than the action. After the last change lands, check that trunk contains the behaviour. Compare it against what the stack was meant to deliver. It takes a couple of minutes, and it turns "merged" back into something you can rely on. I have written before about how a diagnosis becomes trustworthy when you return to the evidence afterwards; delivery deserves the same return visit.

The human side of it

There is a people issue underneath this as well. A stack of a dozen or more changes represents a lot of someone's careful work, and a lot of someone else's reviewing time. When a mis-targeted merge happens, the instinct is to treat it as a personal slip. I think that is the wrong lens, and an unhelpful one commercially. If the process only works when nobody ever clicks the wrong thing, the process is fragile, and the person who hit the rough edge is simply the first to find it.

Better to make the safe path the easy path. Protect the delivery branch so changes cannot land in it without the expected review. Make stacked branches obviously temporary through naming. Agree in the team that retargeting is part of the merge, not an afterthought. And when a mistake does happen, report it plainly and early, which is exactly what happened here. Being able to say "this went into the wrong branch" within a day, without anyone bracing for blame, is worth more than any tooling.

None of this is an argument against stacking. Small, ordered, reviewable changes are kinder to reviewers and cheaper to fix when they are wrong. It is an argument for being precise about vocabulary. Merged is a fact about a branch. Delivered is a fact about a release. The skill is noticing which of the two your team is actually claiming, and checking the one you meant.