Best Practice: Always do Git pull with rebase

TLDR: It is best practice to always rebase your local commits when you pull before pushing them.

See below which is duplicated from https://sdqweb.ipd.kit.edu/wiki/Git_pull_--rebase_vs._--merge

Git pull --rebase vs. --merge

This page briefly explains the difference between rebasing and merging in git while pulling. Both techniques are used to combine your local unpublished changes with the published remote changes. There is another wikipage on how to rebase or merge a branch.

If you want to understand the details of rebasing and merging for changes and branches, then syou should read a blogpost by Mislav Marohnić and the chapter on rebasing and merging from the Pro Git book.

rebasing

If you pull remote changes with the flag --rebase, then your local changes are reapplied on top of the remote changes.

git pull --rebase

merging

If you pull remote changes with the flag --merge, which is also the default, then your local changes are merged with the remote changes. This results in a merge commit that points to the latest local commit and the latest remote commit.

git pull --merge

best practice

It is best practice to always rebase your local commits when you pull before pushing them. As nobody knows your commits yet, nobody will be confused when they are rebased but the additional commit of a merge would be unnecessarily confusing. Published commits are, however, usually merged, for example when branches are merged.

To avoid typing --rebase whenever you pull you can config git to use it as default:

git config --global pull.rebase true

If you want to combine local commits before pushing them upstream, for example, because you discovered a typo or bug after a commit, you can do this interactively:

git rebase -i

If you want to know the details or have an old git version, follow the literature pointers above.