Tag: remotes

How to use a double verbose to print the name of the upstream branch on command line – 121

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.

How to view your branches from the command line – 120

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.

How to deal with a merge conflict when doing a Pull from a remote branch into a local branch in Visual Studio – 119

Suppose this time you have conflicts when you do a Pull, meaning your local branch had a conflicting change that was committed locally (but not yet pushed – see Outgoing Commits 1 in screenshot below) and someone else (let’s say you via GitHub.com UI) made a corresponding conflicting change on the remote.

Here’s the UI setup in Team Explorer. Click on Pull.

Git halts the pull operation (at the merge portion) when it detects the conflicting changes, as expected.

From here it should be familiar territory by now. Clicking conflicts brings you to a merge conflict screen.

Clicking Merge brings up the 3 way merge tool (or choose a take remote or a keep local). If you go the Merge tool route, make sure you click “Accept Merge” at the top. Gets me every time.

Once you’ve accepted the merge (or choose to use the remote or local version), click Commit Merge.

Now we have to commit those our resulting merge. Click Commit Staged in Changes pane in Team Explorer.

and you’re done! Reviewing the local master history shows the merge commit now as the tip.

Still thinking re yesterday how a Pull is different than a Fetch + Merge. I guess if you know you want to download changes, but not ready to deal with any potential conflicts at this time (e.g. going offline for a while or got other things to do right now), Fetch is the way to go. If you know you’re ready to start playing with the code on your local branch, then Pull is the way to go, I think.

How to download and merge commits from a remote branch on your local branch – 118

Today’s tip shows how to combine doing a Fetch and a Merge by using the Pull command.

Suppose you have some incoming commits that you’re ready to merge into your local branch. In this example, I’ve create a new file on master on GitHub and I want to bring that commit into my local master branch.

Instead of fetching to review the commits that are going to be applied, we’ll assume you’ve already looked at GitHub to see what will be merged in.

The result of the Pull command shows a message at the top of the Team Explorer.

Viewing the history on the master branch shows the tip (the top of the branch) having the newly merged in commit from GitHub.

This begs the question: Why use Fetch? Why not always do a Pull? I believe the answer is

if you want to verify what commits have been downloaded
if you want to know if you’ll run into any merge conflicts before doing the Pull (the merge portion of Pull). However, I’m not sure how you can know if you’re going to have any merge conflicts, if you haven’t first merged the commits somewhere. I guess you could manually review the changes. Perhaps someone reading this knows what I’m missing.