Git merge conflicts – “commit” VS “rebase –continue”
I know that once conflicts have been resolved you have, to my knowledge, 2 solutions :
- Git: add vs push vs commit
- Git: Remove directory with quotes and backslashes from repo
- Best Practice for Git Repositories with multiple projects in traditional n-tier design
- git-shell - New repositories
- Move an SVN respository when the server is dead
- Configure git secondary repo
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 ?
One Solution collect form web for “Git merge conflicts – “commit” VS “rebase –continue””
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)
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.
Further research confirms my suspicions that the
git commit method is dangerous and may leave your repo in an undesirable state. See here:
and here: Forgot "git rebase –continue" and did "git commit". How to fix?