CODEWITHSUNDEEP
gitmergerepositoryconflict
Mickäel A.
Mickäel A.

Reputation: 9357

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 :

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 ?

Upvotes: 3

Views: 998

Answers (1)

pattivacek
pattivacek

Reputation: 5823

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?

Upvotes: 7

Related Questions