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?

Solution 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.

Solution 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.

Comments

[sab]

So, do a git pull --rebase is safe?

[Luis]

Safe in which sense? A rebase changes the starting point, the difference between one or the another is that git pull --rebase does a massive rebase. I wouldn't recommend rebasing in shared branches, so I wouldn't recommend git pull --rebase. Do a simple git pull instead.

[dnuttle]

The help for git pull mentions this under the --rebase option: "When true, 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." If you run a git fetch and then a git rebase, you don't get remote changes merged into your branch, as far as I can see. You do with a git pull --rebase.

[dnuttle]

From what I see, a git pull --rebase does more than a git fetch and a git rebase. Those two will not merge in any changes on the remote, but git pull --rebase will. So if you do git pull --rebase master, all changes on the remote for the master branch will be merged into your branch, but your local master branch will not be touched.

[Green]

Not clear. What so special about fetch? Why did they make distinction like that?

[Noam Gal]

Running git pull --rebase causes the post-merge hook to execute. Running git fetch and then git rebase does not execute the post-merge hook. So the first is not a shorthand for the other. What I am still trying to understand is if there are any more differences between the two approaches. Either accidental, or semantic.

[Noam Gal]

OK, this post explains some differences between pull --rebase and fetch + rebase -gitolite.com/git-pull--rebase

[mochadwi]

the gitolite.com/git-pull--rebase explained everything, the git pull --rebase is a favored when working on a features/private branches to merge/rebase (the so-called public/protected branches)