git pull --rebase vs git rebase : what's the danger?

Question

I don't understand the difference between git pull --rebase and git rebase, without any other options.

I don't understand if they are safe, a good practice, or very dangerous.

Can I break the history of commits by doing a git pull --rebase in local?

Answer 1

I don't recommend rebasing at all but just for private branches. By private I mean branches that you're pretty sure only you have pulled.

A rebase changes the starting point of the branch to some newer commit, thus merging all the commits to that point. This could lead to merge conflicts to people that had in their repository the old branch base. I would recommend plain merge always and leave rebasing only for certain situations (feature branches, for example).

Regarding your question:

• git rebase rebases the branch you want.
• git pull --rebase performs a fetch + rebase in the branches you pull. Normally a pull would fetch + merge.

Answer 2

git pull --rebase is a shorthand for git fetch and then a plain git rebase, as opposed as to the default git merge. The practical difference is that applying only the latter would not fetch any new commits from your remote prior to rebasing your code on top of, as it would only take into account what your local repository's already aware of.

It's also worth mentioning that merging conflicts would appear in the same way as a regular git pull.