Git: rebasing a conflicted merge commit

After finishing working on a topic branch, I merged the topic branch into master like following:

          o---*---o---o topic
         /             \
o---o---o---*---o---o---+ master

The commits marked with ‘*’ modified the same code, hence merging lead to merge conflicts that were resolved in the merge commit (marked with ‘+’).

  • How to revert to changes I committed?
  • How to override unmerged git checkout with upstream version
  • Eclipse EGit Checkout conflict with files: - EGit doesn't want to continue
  • Why does git sometimes mark added lines as changed lines (i.e. an empty conflict over an added piece of code)
  • How can I author changes that are not prone to merge conflicts?
  • How to commit a long Git merge in the middle of resolving conflicts
  • While I merged and resolved the conflicts, my colleague pushed new commits to master (marked as ‘n’), resulting in following history:

              o---*---o---o topic
             /             \
    o---o---o---*---o---o---+ master
                         n---n origin/master

    Now, pushing my local master branch of course leads to an error, as it’s no fast-forward-push, so I have two choices:

    1. Throw away my work, reset master to origin/master and redo the merge. I’d like to avoid that as I’d have to resolve the conflicts all over again.

    2. Rebase master onto origin/master and push. Here comes my problem: doing this rebase (even when using the -p switch) does not work smoothly, the merge commit shows the same conflicts again, even though the new commits (‘n’) didn’t change anything touched by the topic branch. So I’d have to resolve the conflicts again during the rebase and would have the same result as with option 1.

    What I’d like to achieve is rebasing the merge commit ‘+’ without having to resolve the conflicts again:

              o---*---o---o-------- topic
             /                     \
    o---o---o---*---o---o---n---n---+ master & origin/master


    The rerere switch is enabled but didn’t seem to help in any way; do I have to do anything more than setting config.rerere to true to fix my problem?

    Edit 2:

    Merging the merge-commit (‘+’) to origin/master would also work (as proposed in the comments and an answer) but would lead to a kind of ugly history which I’d like to avoid by having one merge commit only.

  • How do I display the git sha in my ionic app
  • What is the .git/branches folder used for?
  • Rewriting Git History: How do I remove a sign-off?
  • git grep by file extensions
  • How do I check if a file exists in a remote?
  • Git - how to find first commit of specific branch
  • 3 Solutions collect form web for “Git: rebasing a conflicted merge commit”

    The first way would be the best. Undo your merge and redo it to get your colleague’s changes into the merge commit. But you don’t need to throw the changes away.

    Since you know that your colleague’s changes didn’t affect the files that you resolved the conflicts in. You could create a new branch (we’ll call it conflict-fix) from your current state of master. Reset your branch and redo the merge.

    Rather than using git mergetool or whatever editor that you use. You can bring the file into master from your other branch using git checkout conflict-fix -- <file names>. git add the files and commit to complete the merge. Then you can delete the conflict-fix branch.

    This is fairly easy to do and will result in the single merge commit that you are looking for plus allowing you to push your changes. If the new commits affected the files that you resolved the conflicts in you would have to redo them anyways.


    I am not completely familiar with git rerere but that should have worked. However based on your comment, you should not need to rebase. You would still have undone the merge commit, git fetch the updates and re-performed the merge. You would have to just call the git rerere command and it would have resolved the conflicts in the files for you. With your tree looking like this:

              o---*---o---A topic
             /             \
    o---o---o---*---o---o---+ master
                      n---n origin/master

    You would do the following:

    git reset --hard A
    git checkout master
    git pull
    git merge topic
    git rerere
    //Fix other conflicts
    git push

    And you should end up with:

              o---*---o---o-------- topic
             /                     \
    o---o---o---*---o---o---n---n---+ master & origin/master

    There should be no need to rebase anything.

    What if you rebase topic on top of master, then reset master to the previous commit and pull from the remote, so that you’d have this:

             /             \
    o---o---o---*---o---o---+ topic
                         n---n master & origin/master

    And then you merge topic into master, resulting in this (new merge commit marked with ‘#’):

             /              \
    o---o---o---*---o---o----+ topic
                        \     \
                         n--n--# master

    Does that cause conflicts? Would it work for you?

    rerere is the way to avoid this being such a hassle, but if you didn’t have it enabled before you did the first merge it doesn’t help you. You can know if it is enabled because it will give messages about ‘recording preimage’

    I ran into this myself recently because I had a new development machine and forgot to enable rerere before an ugly merge. There isn’t a great git only solution to this scenario, but the following is the easiest recovery of this situation that I could come up with.

    1. Make sure your working directory is exactly the merge result (git reset HEAD –hard) and copy the source tree from your merge commit somewhere safe
    2. reset your local branch back before any merged commits (git reset –hard master~ or git reset HEAD~n where n is how far back you need to go)
    3. git pull
    4. git merge topic
    5. copy source files back into your working tree overwriting.
    6. git mergetool (to handle any deleted vs modified conflicts)
    7. commit and push

    Since we were working with gerrit I also made sure that the Change-Id was the same as my previous merge commit so I could verify that nothing had gone wrong.

    Git Baby is a git and github fan, let's start git clone.