Reasons to use "git pull --rebase" by default

Rebase is a really sharp knife. Sometimes a really sharp knife is what you need, but it's also possible to accidentally injure yourself.

(thanks to Bill Blunn for the imagery).

Reasons to use "git pull --rebase" and not "git pull" (which merges by default):

• Prevents massive weird conflicting-with-yourself problems if anyone rebases that branch later, e.g. just before merging to master
• Keeps all the commits together in a bunch at the top of the tree so you can easily identify them visually
• Allows "git diff master..HEAD" to work without including unrelated changes

Reasons not to use "git pull --rebase" and stick with "git pull" (using merges):

• It's the default, so most people will use it, and their merges will clash with your rebases

Comparison table:

issue	git pull (default: merge)	git pull --rebase
git log, in a feature branch	pro: you always see when master was merged con: your commits will be interleaved with others commits (less of a problem for short-lived branches)	pro: root of feature branch is transparently moved to head of master pro: all your commits are kept bunched together con: you don't know when master was merged con: you have to notify everyone downstream
diff feature branch against master	con: it's more difficult to diff against master	pro: "git diff master" just works
mixing rebase and merge	con: you can't rebase without weird conflicts	con: you can't merge downstream without weird conflicts (not sure about this one)

(thank you tablesgenerator.com)