When should I use git pull --rebase instead of git pull?

Question

I have a local commit [A] and a branch which points at commit [B]. I need to pull changes before pushing the commit.

Scenario 1:

Changes of commit [A] do not affect anything changed on commit [B]

git pull should be fine, pull should not overwrite anything. Same for using git pull --rebase .

Scenario 2:

Changes of commit [A] and commit [B] affect the same file

git pull should be fine, git should automerge everything. Same for using git pull --rebase .

Scenario 3:

Changes (or deletions) of commit [A] and commit [B] affect the lines of code.

git pull results into merge conflicts which I need to remove manually. Same for using git pull --rebase .

Am I wrong? In which cases I need to use git pull --rebase ? If you pull changes you need to rebase the commit anyway, either by auto merge , no merge or solving merge conflicts .

Answer 1

You can use git pull --rebase in all three cases. However, in the scenarios 2 and 3, you will have a new merge commit. The message will say that you are merging Branch 'foo' into branch 'foo' and with branches that have a lot of changes can make the history really confusing. Using git pull --rebase will not have these merge commits and will show a fairly straight forward history in the git log.