In Tip 116 you saw you to create a local copy of a remote branch in VS. In today’s tip, you’ll learn how to do this from the command line.
First, let’s verify our current list of branches.
Next, you can use the following git command (provided you only have one remote)
$ git checkout I-am-a-new-branch
It seems that you don’t have to specify the `origin/` part. Git knows to look for corresponding tracking branches.
And you’ll have your local branch.
As I’ve mentioned time and time again, I hate shortcuts when learning things for first time. This SO answer tells me there’s a more complete way.
$ git checkout -b <branch-name> origin/<branch-name>
I gave this a try with my gh-pages branch and sure enough it worked!
In Tip 117 you saw how to fetch down updates from a Git remote in Visual Studio. Note: I said “fetch down” instead of “pull down” because tip 117 only fetches the data. The result is the data for the remote tracking branches is updated, but not applied to your local branch. Hence the “incoming commits” terminology in Visual Studio.
Today you’ll see how to rinse and repeat for the command line.
First, let’s verify the currently listed branches our local remote is aware of.
$ git branch -a
Second, let’s add a new branch to the remote on GitHub.
Third, let’s sanity check that no magic sync’ing has happened behind the scenes.
$ git branch -a
And you’ll see the same number of remote tracking branches. (yes, I took a second screenshot. I’m too lazy to think about optimization 🙂 TBH I have to verify what I’m writing here!
Fourth, run the git command to fetch
$ git fetch origin
I know you can do just `git fetch` but I don’t like learning shortcuts first.
I’m not sure if the branch on the left is the remote tracking branch or if it is the one on the right. My guess is the one on the left hand side represents the branch from GitHub and the one on the right represents the remote tracking branch.
Nonetheless, you now have a new remote tracking branch as shown below.
Ah Git. It is the gift that keeps on giving if you’re into studying developer tool usability.
Suppose you wanted to get the last commit ID and message while listing all your branches. The `–verbose` or `-v` for short will provide you with that information, e.g.
$ git branch –verbose -a
Yay! But while I was scanning the documentation, I came across this usability gem*
If given twice, print the name of the upstream branch, as well. (see also git remote show <remote> ).
Yep, if you do a
$ git branch -vv -a
you’ll get even more information! Note the blue text depicting the upstream branch.
*Specifying the –verbose option twice reminds me of old school text-adventure games where you’d have to look twice in the same location to find a second item. If you thought to do that, you’ll get a bonus or something. Now I might have to search the Git documentation for the common commands to see what other options exist where you have to specify a parameter twice!
P.S. I can’t find in Visual Studio where to see the upstream branch. You can see all remote branches in the history view, but that’s not quite the same. Perhaps since in Team Explorer (as far as I can tell) 1. you can’t rename a branch checked out from a remote tracking branch and 2. can’t checkout more than one remote tracking branch, it’s assumed that the upstream branch has the same name as your local branch. That’s my guess.
Now that you’ve seen how to do fetches, merges, and pulls from a remote tracking branch within Visual Studio, let’s rinse and repeat from the command line. Personally, it’s been easier to first grasp these concepts using Visual Studio, then rinse and repeat at the command line level.
I have to know the truth behind what the UI is doing 🙂
If you want to view the full list of remotes, similar to the full list shown in Team Explorer – Branches
From the command line, you can do
$ git branch -a
You’ll see the same list (well almost the same list. I’m not sure yet what the remotes/origin/HEAD is doing yet… stay tuned unless someone wants to beat me to the answer in the comments!)
Note how the local branch `for-review` is listed first (which kinda gets blended in color-wise with the command), then master, then the remote tracking branches.
Something that has confused me for a long time until I wrote yesterday’s post was whether “remotes/origin/why-not” was the same as “origin/why-not” or even the made-up “remotes/why-not” (which I don’t think a branch is ever referred to as such). Now that I can visualize what both the command line and Visual Studio are doing, it’s easier to get my head wrapped around these remote tracking branches.