Git: fetch and merge, don’t pull
longair.net
longair.net
From the manpage for git pull: git-pull - Fetch from and merge with another repository or a local branch
Git pull is identical to git fetch && git merge $remote_branch. He's saying that it prevents you from learning how branching works. So, if he were explicit, he should say 'Don't use git until you know how branching works at some level.', which is good advice. Not using git pull is a pretty sensational way to get at that nugget.
* If you `git pull`, you don't get the chance to diff between your local branch and what you just fetched and check if you really want to do that merge, using `git fetch` and `git merge` makes it more likely you'll do that check
* Getting used to `git fetch` means if you need to diverge from the straight `git fetch; git merge` workflow (because you want to rebase, or you have a high number of active topic branches floating around) you're already halfway there.
I think the best approach is to code on a separate branch while keeping the base unchanged and do the rebase (or merge) when the code is complete. That way, you at least have a branch of code that you know is working, and when you merge, you immediately know that any issues are caused by something that changed between the old and the new base. And you still can do mid-development rebases if there is a need for them.
Here are some advantages:
1. Work you happened to do after a merge doesn't spuriously appear to depend on that merge.
2. You can do conflict resolution incrementally during the rebasing process (commit-by-commit instead resolving a merge conflict all at once).
3. Linearizing more of your history improves the precision of git bisect. You're much more likely to have the result of a bisect point to a simple commit rather than a complex merge when there are fewer merges.
The two major disadvantages I see are:
1. Pulling and rebasing is more complex than pulling and merging (more steps and more decisions).
2. You have to be careful not to rebase a branch you have "published".
You're not supposed to do work on the same feature after a merge. I'm not advocating pulling master (or whatever the base branch is) often and merging whenever, so that you end up with loads of pointless merges. Once your feature is done, you merge once. This makes point 3 pretty much moot, since bisect handles merges just fine.
Sometimes you need to update your code on top of a new base because of some important bugfix or something, and then it's fine to rebase, but I don't think it should be the default.
I'll accept point 2, though I think git's merging is good enough that it's not noticeable in most cases. If you rebase you also lose information about the conflicts which may be undesirable. Someone might want to review your merge to see if you have solved the conflicts correctly.
hg pull == git fetch
git pull == { hg pull; hg merge; }
Actually, in Mercurial `pull` does not ever merge. It can update if you ask it to (with `-u`), but it won't merge.
`hg fetch` (standard extension) can merge (it's basically "pull and update, if update fails merge"), but it might go the way of the dodo pretty soon[0]
[0] http://www.selenic.com/pipermail/mercurial-devel/2011-August...
$ git fetch
$ git checkout master
$ git merge origin/master