Search code examples
gitmergerepositoryconflict

Git merge conflicts - "commit" VS "rebase --continue"


I just finished resolving some conflicts due to a pull from the remote repository of my project.

I know that once conflicts have been resolved you have, to my knowledge, 2 solutions :

  • git rebase --continue
  • git commit -m "foobar"

I was just wondering if there are any differences between those 2 operations, in this context only, as I know they are fundamentally different in their basic form ?


Solution

  • EDIT #2:

    If you initiated this situation with git pull, the expected resolution is to use git commit, because you are creating a new commit to represent the successful merge. If this situation was initiated with git pull --rebase, you would want to use git rebase --continue as mentioned in my original answer, as this will reuse the same commits without creating any new ones.

    Original answer (in which I assumed this was initiated with git pull --rebase):

    I can tell you that the recommended method is to use git rebase --continue. (See here: http://git-scm.com/docs/git-rebase)

    The git commit method may work, but it may change your commit history if you don't use the -C flag, which is what resolving a git merge will recommend. I suppose it is also worth mentioning that the -m flag will change the log message, whereas the git rebase --continue will reuse the old commit message without asking.

    EDIT:

    Further research confirms my suspicions that the git commit method is dangerous and may leave your repo in an undesirable state. See here: http://www.tigraine.at/2011/08/10/dont-commit-when-you-rebase and here: Forgot "git rebase --continue" and did "git commit". How to fix?