After reverting a merge in Git, why does re-merging that branch restore nothing?

## The setup 1. `feature` is merged into `main`, producing merge commit `M`. 2. Something is wrong, so `main` gets `git revert -m 1 M`, producing revert commit `R`. The tree on `main` no longer contains the feature's changes. 3. The feature is fixed on `feature` and merged into `main` again. 4. The original changes are still missing. This surprises people badly, sometimes in production, because step 3 reports success. ## Why it happens Git's merge decides what to bring in by comparing three trees: the two branch tips and their **merge base**, the best common ancestor. Ancestry is the input, and ancestry was never undone. After step 1, every commit on `feature` is reachable from `main` through `M`. `R` is an ordinary commit that changes files; it adds nothing to and removes nothing from the graph. So at step 3 the merge base already contains all the original feature commits. From the merge's point of view, that side contributed nothing new — the only changes it can bring in are the ones made on `feature` *after* `M`. Meanwhile the mainline side does have a change relative to the base: `R`, which deleted that content. So the merge result keeps the deletion. Nothing is lost or corrupted; Git did exactly what the graph told it to. The general statement is worth memorising: **reverting a merge undoes the content of a merge, but does not undo the fact of the merge.** ## Getting the work back There are two sound approaches. **Revert the revert.** On the target branch, `git revert <R>` produces a commit that re-applies what `R` removed. Now the content is back and the branch can be merged again normally, with the merge only contributing what came after. This is the mechanical, minimal answer, and it makes the whole story visible in history: merged, withdrawn, restored. Its downside is bluntness — if `M` brought in twenty commits and only one was bad, reverting the revert restores all twenty, so you usually pair it with a targeted fix for the actual problem. **Rebuild the work as new commits.** Recreate the changes on a fresh branch so they are new objects that no ancestor contains — for example by rebasing the branch onto the current mainline, or by cherry-picking its commits onto a new branch. The merge then behaves normally because the content genuinely is new to the graph. This is preferable when the original branch was messy anyway, or when you want to re-land a subset rather than everything. What does **not** work is merging harder: repeating the merge, using a different strategy, or forcing it. None of those change reachability. ## Avoiding the situation - **Prefer reverting the individual commits** rather than the merge, when the merged work is likely to come back. Reverting commits one by one has the same content effect, and re-landing later is far less surprising because you can revert those reverts selectively. - **Do not merge back and forth casually** between a branch whose merge was reverted and the mainline; the asymmetry propagates. - **Leave a note in the revert commit message** saying the branch will need special handling if it returns. The next person will not reconstruct this from the graph. ## How to diagnose it when you meet it cold Someone reports "my changes vanished after we merged again". Check three things: does the file's history show a revert of a merge (`git log --oneline --merges` plus looking for a `Revert "Merge …"` subject); is the feature branch's tip already an ancestor of the target (`git merge-base --is-ancestor <feature> <target>`); and does `git log <target>..<feature>` show nothing, meaning the branch has no commits the target lacks. Those three answers together identify this situation precisely, and the fix follows from the choice above.