Re-merge a branch after reverting its merge

Does this match your situation?

• 'Already up to date.' when merging a branch whose changes are clearly missing.
• The merge succeeds but adds none of the branch's files back.
• Only commits added after the revert come through; the original ones do not.
• A pull request shows no changes even though the branch obviously differs.

Step-by-step fix

1. Find the revert commit

   You need its hash. Reverts made by GitHub or GitLab are titled 'Revert "..."', which makes them easy to spot in the log.

   step 1Copy

   git log --oneline --grep='^Revert' -n 10
   git log --oneline --merges -n 10
   

2. Revert the revert

   This creates a new commit reinstating the content, and it is the approach Git's own documentation recommends. The feature branch's original commits stay merged as far as history is concerned; you are only putting their effect back.

   step 2Copy

   git switch main
   git revert <revert-commit-hash>
   git push
   

   ✅Any new work added to the feature branch since then still needs merging afterwards, as a separate normal merge.

3. Then merge the branch as usual

   With the content restored, a normal merge brings in whatever was added after the revert. Expect conflicts if the same lines were touched twice.

   step 3Copy

   git merge feature/login
   git push
   

4. Alternative: rebase the feature branch instead

   Rebasing gives every commit a new hash, so Git no longer recognises them as already merged and replays the changes in full. This produces a cleaner result than a revert-of-a-revert, at the cost of rewriting the feature branch.

   step 4Copy

   git switch feature/login
   git rebase --onto main <revert-commit> feature/login
   git push --force-with-lease
   
   git switch main
   git merge feature/login
   

   ⚠️Rewrites the feature branch. Coordinate with anyone else working on it.

5. Or start a fresh branch by cherry-picking

   When the history is tangled enough that neither option is comfortable, lifting the commits onto a new branch sidesteps the merge tracking altogether and is easy to reason about.

   step 5Copy

   git switch -c feature/login-v2 main
   git cherry-pick <first-commit>^..<last-commit>
   git switch main
   git merge feature/login-v2
   

Why this works

Merging is decided by ancestry, not by content. Once a merge commit exists, every commit on the feature branch is an ancestor of main, and Git's answer to 'what still needs merging?' is correctly 'nothing' — which is why it says 'Already up to date' even though the files are gone. Reverting the merge did not remove those commits from history; it added a new commit whose content undoes theirs. So the branch remains merged and its effect remains cancelled, and merging again cannot help, because merging only ever brings across commits that are not already ancestors. That is why both real fixes work at a different level: revert-the-revert changes content without touching ancestry, and rebasing changes ancestry by giving the commits new hashes.

If that didn’t work

• git log --oneline main..feature/login lists what Git still considers unmerged — often empty, which confirms the diagnosis.
• git diff main feature/login shows the content difference regardless of ancestry.
• git merge --no-commit --no-ff feature/login lets you inspect the result before creating anything.
• Squash-merged pull requests behave the same way for the same reason.

How to stop it happening again

• Prefer reverting individual commits over reverting a whole merge when the branch will return.
• If you must revert a merge that will be re-merged, note the revert hash in the pull request.
• Delete and recreate short-lived branches after a revert rather than reusing them.
• Read Git's own 'reverting a faulty merge' guide before reverting a merge on a shared branch.

Commands used in this guide

Frequently asked questions