Git merge conflicts - “commit” VS “rebase --continue”

Question

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 ?

Answer 1

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?