Irbis
Irbis

Reputation: 1511

Resolving merge conflicts after reverting a merge commit

I have merged a feature branch into develop. After that I have found a bug in the feature branch code so I have reverted the merge (branch develop) :

git revert -m 1 <merge-commit-hash> 
git push origin develop

Next I have fixed the bug on the feature branch. In the meantime some other branches have been merged into develop. I have created a pull request (feature branch -> develop) with the fix but it can't be merged into develop due to conflicts. I would like to have a pull request without conflicts. When I try to merge develop into feature branch to resolve conflicts the code from the feature branch is reverted (probably due to earlier revert of merge). How to fix that ?

Upvotes: 1

Views: 2524

Answers (1)

j6t
j6t

Reputation: 13617

You have this history (time flows left to right):

        ...   ...
            \     \
----------M--o--R--o    <-- develop
         /
--1--2--3--F            <-- feature

You have created commits 1, 2, 3 on your feature branch and merged it into develop at commit M. Then you discovered that there is a bug and reverted it at commit R (before or after other branches have been merged; it does not matter).

Now you have fixed the problem with commit F and you want to merge the feature again. This brings a lot of trouble (merge conflicts), because F depends on the changes you made on the feature branch, but develop no longer has them (you have reverted them in R).

One way out is that your revert the revert and then merge the updated feature branch:

git checkout develop
git revert R
git merge feature

That should not produce the merge conflicts, but result in this history:

        ...   ...
            \     \
----------M--o--R--o--R'--N    <-- develop
         /               /
--1--2--3--F------------'      <-- feature

R' is the reversal of the revert R.

Another method is to make Git think that the earlier merge has never happend using git replace --graft as described in this answer.

Yet another method is to create a completely new feature branch. Assuming 1 is the first commit that was merged in M, it could go like this:

git checkout feature
git rebase --force-rebase 1^
git checkout develop
git merge feature

git rebase --force-rebase 1^ ensures that commits 1, 2, 3, F are copied and creates a new branch that forks off at the same point that the original branch forked off. You get this history:

        ...   ...
            \     \
----------M--o--R--o--N    <-- develop
         /           /
--1--2--3--F        /      <-- abandoned feature branch
--1'--2'--3'--F'---'       <-- feature

Of course, you can choose a new fork point for the feature branch. R would be the natural choice.

Upvotes: 2

Related Questions