When should I use git pull --rebase?

Question

I know of some people who use git pull --rebase by default and others who insist never to use it. I believe I understand the difference between merging and rebasing, but I'm trying to put this in the context of git pull. Is it just about not wanting to see lots of merge commit messages? Or are there other issues?

Answer 1

I think it boils down to a personal preference.

Do you want to hide your silly mistakes before pushing your changes? if so, rebase is perfect, it allows you to later squash your commits to few (or one) commit.

I personally don't mind publishing all my silly mistakes, so I tend to merge instead of rebase.

Answer 2

I think you should use git pull --rebase when collaborating with others on the same branch. You are in your work->commit->work->commit cycle, and when you decide to push your work your push is rejected because there's been parallel work on the same branch. At this point I always do a pull --rebase. I do not use squash (to flatten commits), but I rebase to avoid the extra merge commits.

As your git knowledge increases you find yourself looking a lot more at history than with any other vcs I've used. If you have a ton of small merge commits, it's easy to loose focus of the bigger picture that's happening in your history.

This is actually the only time I do rebasing, and the rest of my workflow is merge based. But as long as your most frequent committers do this, history looks a whole lot better in the end.

Answer 3

You should use git pull --rebase when

• your changes do not deserve a separate branch

Indeed -- why not then? It's more clear, and doesn't impose a logical grouping on your commits.

---

Ok, I suppose it needs some clarification. In Git, as you probably know, you's encouraged to branch and merge. Your local branch, into which you pull changes, and remote branch are, actually, different branches, and git pull is about merging them. It's reasonable, since you push not very often and usually accumulate a number of changes before they constitute a completed feature.

However, sometimes--by whatever reason--you think that it would actually be better if these two--remote and local--were one branch. Like in SVN. It is here where git pull --rebase comes into play. You no longer merge--you actually commit on top of the remote branch. That's what it actually is about.

Whether it's dangerous or not is the question of whether you are treating local and remote branch as one inseparable thing. Sometimes it's reasonable (when your changes are small, or if you're at the beginning of a robust development, when important changes are brought in by small commits). Sometimes it's not (when you'd normally create another branch, but you were too lazy to do that). But that's a different question.

Answer 4

I don't think there's ever a reason not to use pull --rebase -- I added code to git specifically to allow my git pull command to always rebase against upstream commits.

When looking through history, it is just never interesting to know when the guy working on the feature stopped to sync up. It might be useful for the guy while he's doing it, but that's what reflog is for. It's just adding noise for everyone else.