Category: Git(Hub) Tip of the Day 2017

How to do a fast forward merge in Visual Studio – 092

Yay!! I’m over 25% of the way into this series!! Which also means OMG is 2017 already 25% over yet?!?!

Today’s tip demos how you can do a straight forward merge in Visual Studio. No conflicts, etc.

Suppose you have have a method called DoNothing() that lives in a donothing branch.

1. Switch to the branch you want as a target

Double-click on the branch name. The bolded name will be the target branch. Checking out the target branch mimics Git command line functionality.

master branch checked out and bolded

2. Right-click the target branch and select Merge From…

Merge From... context menu

3. Click the merge button

We’ll get to what the checkbox means in a bit. As if I could stay away from blogging about a checkbox in VS!  =D

Merging donothing into master

And if all goes well, Team Explorer will give you a message

Repository updated to commit id in Team Explorer status bar

We’ll cover merge conflicts later.

Note this was a fast forward merge because there was nothing to merge, so there’s only the linear graph. A fast-forward is where Git realizes that you could have done each commit on that target branch, so it makes it look like that in graph form.

linear graph in commit history

To visualize what we’ve done in Git, here’s the setup. We have one commit in donothing that’s ahead of master.

branch donothing one commit ahead

Now we checkout master and do a git merge

git merge from donothing into master

Note how the tool assumes it’s a fast-forward merge. The tool must assume this because the tool doesn’t have a concept of a working directory or staging, so it can’t diff any files to detect conflicts. So the tool assumes there are no conflicts, hence a fast-forward merge.

We’ll look at non-fast forward merges next. 

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.