At work, I use Mercurial. At home, I use Git. Both are distributed source control systems, and both are systems I hadn’t yet used till this year. (A previous job had me working with Perforce, while I was still muddling through Subversion and CVS before that.)

I got familiar with Mercurial before I did any extensive work with Git, so I approached Git with the mindset of “How is this done in Mercurial?” That works for some functions better than others.

Take the notion of pulling remote branches. In Mercurial, you do this:

hg pull -b <remote-branch-name> <repo-name>

This command will create that new branch in your clone of that repository. Git has a similar command:

git fetch origin <remote-branch-name>

This command retrieves information about a remote branch, but it won’t create that branch in your clone. Rather, the new branch needs to be created in the clone first before remote changes are pulled in.

git checkout -b <remote-branch-name>
git pull origin <remote-branch-name>

I could be wrong about that, but so far, it’s been working for me.

UPDATE, 9/29/2014, 12:33: While git pull might work, it’s actually a somewhat redundant step. git pull is really a combination of git fetch and git merge FETCH_HEAD. So if I were to spell out all the commands in this example, it would look something like the following:

git fetch origin <remote-branch-name>
git checkout -b <remote-branch-name>
git fetch origin <remote-branch-name>
git merge FETCH_HEAD

In essence, we’ve called git fetch twice. The net effect is the same. It’s just not … as correct as it should be. So what should really happen is …

git fetch origin <branch-name> --tags
git checkout -b <branch-name>
git merge FETCH_HEAD

… or …

git checkout -b <branch-name>
git pull origin <branch-name> --tags