Start situation (no unpushed changes, > indicates the current branch):
o C [> master][origin/master] | o B | o A | ... After a git fetch the log structure often looks like
o E [origin/master] | o C' | o B' | o D | | o C [>master] | | | o B |/ o A | ... Now git rebase origin/master master often produces conflicts. Is git pull --rebase smarter and just uses git reset to make master also point to E if master==origin/master initially?
git pull --rebase its similar to what:
git fetch git rebase would do. So in your case will leave the repo like this:
o C [> master] | o B | o E [origin/master] | o C' | o B' | o D | o A | ... Note that the two commits you have different from origin where re-created on top of commit E.
You can pull with rebase instead of merge - that's the way my team works and it works quite well.
From "A few git tips you didn't know about":
Because branch merges in git are recorded with a merge commit, they are supposed to be meaningful―for example, to indicate when a feature has been merged to a release branch. However, during a regular daily workflow where several team members sync a single branch often, the timeline gets polluted with unnecessary micro-merges on regular git pull. Rebasing ensures that the commits are always re-applied so that the history stays linear.
You can configure certain branches to always do this without the --rebase flag:
#make 'git pull' on master always use rebase$ git config branch.master.rebase trueYou can also set up a global option to set the last property for every new tracked branch:
# setup rebase for every tracking branch$ git config --global branch.autosetuprebase always
git pull --rebase is NOT the same as git fetch; git rebase. Unfortunately the git-pull man page is rather cryptic about the difference:
--rebase Rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to the upstream branch and the upstream branch was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes. It turns out that the difference doesn't involve git reset as the original poster guessed - in fact it involves the reflog (see here if you haven't encountered that term before).
For the complete story around the extra magic in git pull --rebase, see this answer: