0

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.

elp
  • 840
  • 3
  • 12
  • 36
  • https://stackoverflow.com/questions/2472254/when-should-i-use-git-pull-rebase – phd Jan 02 '19 at 20:37
  • https://stackoverflow.com/questions/18930527/difference-between-git-pull-and-git-pull-rebase – phd Jan 02 '19 at 20:38
  • https://stackoverflow.com/search?q=%5Bgit%5D+difference+between+%22git+pull%22+%22git+pull+--rebase%22 – phd Jan 02 '19 at 20:38
  • I almost got it, could you post at least one more? – elp Jan 02 '19 at 21:31

1 Answers1

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.

Schleis
  • 41,516
  • 7
  • 68
  • 87