when Git has already merged a change and later reverted it, merging another branch that still contains the original commit usually will not restore that change. Git tracks commit history, not just the final file contents.
Why it happens
A revert creates a new commit that applies the opposite changes. It does not remove the original commit from history.
This matters when a development branch still has the original feature, but the release branch contains both the feature commit and a later revert. A future merge may complete without a conflict while the feature stays removed.
Why the merge behaves this way
Git sees the original feature commit as already merged into the release branch. The revert is also part of that branch’s history. Because the original commit is not new, Git does not apply it again during the next merge.
The confusing part is that the development branch may show the feature in its files. The history still tells Git that the original commit has already been handled.
How to restore the feature safely
- Create a temporary integration branch from the branch that should receive the change.
- Merge the other branch and resolve any real conflicts.
- Revert the earlier revert commit. This creates a new commit that restores the feature.
-
Run the relevant tests and inspect the combined diff.
-
Open a pull request so the history and final result can be reviewed together.
When a hotfix must move between branches
If the source branch contains unrelated commits or reverts, merging the whole branch can bring unwanted history and code. In that case, create a branch from the target branch and cherry-pick only the missing hotfix commits.
Cause: the hotfix branch also contains changes the target branch should not receive.
Fix: copy only the required commits, then test the target branch’s existing features.
Common mistakes
- Assuming identical-looking files guarantee the next merge result. Check commit ancestry and reverts too.
-
Cherry-picking a merge commit instead of the code commit. Select the focused commit that contains the actual fix.
-
Resolving every conflict with one side. Decide which behavior must survive, then verify the final file.
-
Testing only the hotfix. Also test the target branch features that could be affected.
Inspect the revert you are undoing
Review git show REVERT_COMMIT before undoing it: the revert may cover several changes. Reverting a merge also involves its selected mainline parent, so the restoration plan needs extra care. Compare the final target-branch diff and run the affected tests rather than assuming a clean merge restored the intended behavior.
A revert is a new historical decision, not an eraser. Before merging long-lived branches, inspect both the content and the commit history.
Next action: if a reverted feature should return, prepare an integration branch and revert the revert there before merging.
Reference: Git revert documentation.