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 ?
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?