Question

So if I’m using branches that are remote (tracked) branches, and I want to get the lastest, I’m still unclear if I should be doing git pull or git rebase. I thought I had read that doing git rebase when working on a branch with other users, it can screw them up when they pull or rebase. Is that true? Should we all be using git pull?

Answer 1

Git pull is a combination of 2 commands

• git fetch (syncs your local repo with the newest stuff on the remote)
• git merge (merges the changes from the distant branch, if any, into your local tracking branch)

git rebase is only a rough equivalent to git merge. It doesn’t fetch anything remotely. In fact it doesn’t do a proper merge either, it replays the commits of the branch you’re standing on after the new commits from a second branch.

Its purpose is mainly to let you have a cleaner history. It doesn’t take many merges by many people before the past history in gitk gets terribly spaghetti-like.

The best graphical explanation can be seen in the first 2 graphics here. But let me explain here with an example.

I have 2 branches: master and mybranch. When standing on mybranch I can run

git rebase master 

and I’ll get anything new in master inserted before my most recent commits in mybranch. This is perfect, because if I now merge or rebase the stuff from mybranch in master, my new commits are added linearly right after the most recent commits.

The problem you refer to happens if I rebase in the ‘wrong’ direction. If I just got the most recent master (with new changes) and from master I rebase like this (before syncing my branch):

git rebase mybranch 

Now what I just did is that I inserted my new changes somewhere in master’s past. The main line of commits has changed. And due to the way git works with commit ids, all the commits (from master) that were just replayed over my new changes have new ids.

Well, it’s a bit hard to explain just in words… Hope this makes a bit of sense 🙂

Anyway, my own workflow is this:

• ‘git pull’ new changes from remote
• switch to mybranch
• ‘git rebase master’ to bring master’s new changes in my commit history
• switch back to master
• ‘git merge mybranch’, which only fast-forwards when everything in master is also in mybranch (thus avoiding the commit reordering problem on a public branch)
• ‘git push’

One last word. I strongly recommend using rebase when the differences are trivial (e.g. people working on different files or at least different lines). It has the gotcha I tried to explain just up there, but it makes for a much cleaner history.

As soon as there may be significant conflicts (e.g. a coworker has renamed something in a bunch of files), I strongly recommend merge. In this case, you’ll be asked to resolve the conflict and then commit the resolution. On the plus side, a merge is much easier to resolve when there are conflicts. The down side is that your history may become hard to follow if a lot of people do merges all the time 🙂

Good luck!