Tag: branches

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

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.

git branch --v -a

*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 fix the "I’ve started making changes on master. How do I get those to another branch?" using Visual Studio – 090

For 20 years, Visual Studio users have started their workday by launching VS and start coding. Now we have to break that “muscle memory” by stopping to think, “Hmm which branch am I on? Do I need to switch branches first?”

You are allowed to switch to a branch, provided that branch doesn’t already have different changes to the same file. You’ll see the happy case, then the #sadtrombone case.

Help wanted:  This tip is only for saved changes, *not* committed changes. I don’t know how to undo the “oh shit! I’ve committed on master!” *from within Visual Studio* without dropping to the command line. If someone knows, please share in the comments or on twitter! aka please get my attention – references to Samurai Jack seem to work very well 🙂

Happy Case

Suppose you have a Console Application and you need to add a new file called IDoNothing.cs – yep, how I roll.

IDoNothing.cs being added in Changes window

Note that I haven’t committed anything else. These files are only saved.

Team Explorer will still allow you to switch branches. Go to Team Explorer – Branches, and switch to the desired branch.

donothing branch switched to

Then you can commit your IDoNothing.cs file into the donothing branch.

#sadtrombone case

From a previous tip, we’ve made changes to the output in our decorations branch. So let’s switch back to master and make some changes to Program.cs, e.g. adding a new method call.

DoingNothing() method added to Program.cs

We’ve saved the changes, but haven’t committed them. Now when we try to switch to decorations branch we get an error message.

error message: cannot switch becaues uncommitted changes

Yes, that reminds me of the old joke about the helicopter that’s lost over Microsoft HQ. When they the folks on the ground where they are at, they hear, “You’re in a helicopter.” The pilot says, “Thank you!” and plots a new course. The passenger says, “WTF? How do you know what to do after that answer?” He said, “it’s clearly MSFT. You ask a question and get the most technically accurate, but yet not really useful for the given situation answer back.”

Yes, true, you cannot switch because of uncommitted changes, but why is this different than before? Because decorations branch already has a different Program.cs file than what’s in our current branch (master).  In the happy case, by adding a new file, I knew there would be no conflict (and given it’s a Console Application, i don’t have many options for a demo 🙂 But when modifying Program.cs, there’s a conflict, so VS says to see Output Window for details:

> Cannot complete the operation because of existing changes to the following file:
    ConsoleApp1/Program.cs

Now that’s a useful answer! 🙂

How to commit and visualize code on different branches in Visual Studio – 089

Yesterday’s tip visualized what happens in Visual Studio (and in Git) when you create a branch. Today’s tip visualizes committing code independently in different branches.

First, you’ll see how to commit to separate branches in Visual Studio, then we’ll rinse and repeat in the Git Visualization tool.

Committing to Different Branches in Visual Studio

In this example, I’ve rolled back to the Console Application with only output message. We’re going to add the ChangeColor() method and call on a branch called addColor.

ChangeColor() committed to addColor branch in Team Explorer

Once you’ve pressed Commit All to addColor, you’re going to discover that you want to experiment with decorations. You can use Team Explorer – branches to create a new branch called decorations.

You’ll want to use master because you want to keep the addColor changes separate from your decorations branches.

Creating a new local branch from master in Team Explorer

and you’ll want to verify you were on master in the dropdown

creating branch from master called decorations

Add your decorations to your project file

adding more output decoration text

And now commit those changes to your decorations branch.

committing to decoration branch

And now we have 2 different commits on 2 different branches

3 branches in Team Explorer

Visualization of what we just did

First, we’ll want to create and checkout a branch called addColor and make some changes there.

git commit, checkout -b addColor, commit visualization

Next, we’ll want to switch back to master and create a new branch from there.

git checkout master, git checkout -b decorations visualization

Finally, we’ll make a commit on the decorations branch.

git commit on decorations branch visualization

I keep trying to remind myself that whenever I do a checkout, reset, etc. I’m not really going forward and backward in time, but rather I’m moving to a different nodes on a graph. Visualizing what git is doing helps break my timeline mental model.

How to create a branch in Visual Studio – 088

It seems that I have to write these tips in triplicate: 1. command line, 2. Visual Studio, 3. git visualization tool. But that’s been the only way to prove to myself I’m grasping the concepts.

Command line

A college French professor once gave me the advice to never use contractions in class unless I was prepared to never ask him to slow down. I had just learned the equivalent of “I do not know” vs “I don’t know” (something like that).

Applying that advice to software, I don’t want to start using git shortcuts by combining commands until it is clear what the two commands are independently doing. (Yep, I’ll show the shortcut in a second… )

First, you’ll want to create a branch:

> git branch my-branch

Next, you’ll want to switch to that branch:

> git checkout my-branch

git branch addColor; git checkout addColor

Git Visualization

Okay that’s pretty straight forward, but what’s happening conceptually?

git visualization of creating and switching a branch

We are on master when we created a branch called addColor while on master and then switched to addColor.

The take home message is that addColor has everything that master has because we created the branch addColor while on Master.

Git Command Line Shortcut

Before we jump into the IDE, let’s take a sneak peek at that shortcut.

Note: in case anyone is following along at home, I first switch back to master to delete the addColor and then recreate using the shortcut.

The shortcut is

> git checkout -b addColor

deleting branch and then recreating using the shortcut

This shortcut says to checkout to addColor and if it doesn’t exist, create it.

Visual Studio

When you’re in Team Explorer, you can go to Branches, right click on the branch you want your new branch to be based on, right-click, and select New Local Branch From…

New Local Branch From... command in Team Explorer - Branches

Then give your new branch a name (and verify in the drop down you picked the correct branch) and leave the checkbox checked…

checkout branch option in Team Explorer

If you have the Checkout branch checkbox, you’re telling VS to create the branch and do the checkout so you’re now on the addColor branch instead of master.

If you uncheck it, it is the equivalent of creating the branch on the command line, but staying on master.

To confirm you’ve created and switched to the addColor branch, you’ll see that addColor is now in bold.

branches showing addColor now checked out

And the branch is also shown in the Visual Studio status bar.

addColor from status bar

How to create a pull request for a bug fix on a branch on a forked repo that you’ve pushed to GitHub – 044

This might be my greatest worst blog post title ever.

In previous tips, you’ve created pull requests as part of the commit workflow when you’ve edited or added files directly on GitHub. In other tips, you’ve cloned repos, created branches, made bug fixes, and pushed those changes up to your forked GitHub repo. Now you’ll submit those bug fixes to the base repo via a pull request.

First, switch to the branch that contains the changes you wish to propose to the base repository.

switching to windows-fix branch

Now to the right of the branch: switch button, click New pull request.

switching to windows-fix branch

And you’ll see the familiar Pull Request form on the base repo. Remember, PRs are open on the base repo, and not on your forked repo. In fact, you can’t find the pull request tab on your forked repo!

Fortunately, our changes have no conflicts, so we are good to go!

Open a pull request form

In the forms below, you’ll want to provide a helpful comment. The title of the PR is just the name of the branch as a placeholder, so provide something more meaningful.

filled out pull request form

Once the PR form is filled out, clicked the Create pull request button, and volia!

created Pull Request shown in base repo

The base repo now has a Pull Request created, and there was much rejoicing!

You might notice that it says #4 when there’s only been 2 other pull requests for this repo. Issues and Pull Requests share the same number listings. At the time of this writing, the order in which things were created in this repo are as follows: #1 PR, #2 PR, #3 Issue, and #4 the PR you’re looking at now.

How to push a new branch to your repo on GitHub via the command line – 042

I’ve never thought about Feb 11 being the meaning of life day…

Let’s assume on your local repo, you’ve created a branch and made some changes to that branch. Now you want to push up to your repo. It doesn’t matter if your repo is a fork of someone else’s repo or if you created the repo from scratch.

Before I push my changes, I like to review the logs. This is totally optional, but a good sanity check from time to time to make sure you’re not sharing your email address.

To review your logs, use the command

> git log

viewing your logs in git that will go up to github

and I see my email address is using the noreply one from GitHub so I can still get credit for my contributions. (See upcoming tip.)

And now I can push these changes up by using the following command:

> git push origin windows-fix

and you can verify these changes in your GitHub repo.

your recently pushed branches: windows-fix

and if you switch to this branch (by clicking the branch name in the previous image), you’ll see the 3 commits listed there.

windows-fix branch showing the 3 commits

If you’re wondering why I’m doing this blog series, it is because I constantly have to look up these commands. That’s the problem you run into when you haven’t been paid to code in 10 years. I’m having to come up with other creative ways to grok this material. I always think this command is either git push <branch-source> <branch-destination> or git push <repo-destination> <repo-source> which neither is the case. The command is actually git push <remote-name> <branch-name> See github documentation. I always forget this because I think that master is the name of the local repo (from doing git push origin master all the time). But again, this isn’t the case. Master is the name of the default branch (and not the repo).

How to search for a Pull Request based on a branch name – 025

In yesterday’s tip, it was easy to find the desired Pull Request when there’s only been one Pull Request created. Today, let’s say that you want to restore a deleted branch, but you need to search for the Pull Request to get to the Restore button. Deleted branches aren’t shown on the Branches page.

Navigate to the Pull Request tab, and in the search field, 1. delete the search defaults and 2. type in

head:<branch-name>

Notice you’re using head: as the search parameter because there are two branches involved in a Pull Request. The base branch is the branch that the changes are going into. The head branch is the source of those changes.

searching pull requests for head:readme-draft

And in the above screenshot, you see the Updated the readme PR that contains the readme-draft.

You can also search based on base branch using the base:<branch-name> search option. Check out the search documentation for more information.