Chris Gomez

Development topics for the indie programmer

Intro to Git in Visual Studio

More and more, my topics are going to involve you downloading and looking at code.  And that will mean you can get the code from GitHub.  The idea of “social coding” has gone beyond the hot new fad to being the standard for open source projects.

Even for Microsoft developers who are used to waiting for CTP’s and Preview SDKs, this is changing rapidly.  The ASP.NET team has embraced open source, and are developing the next generation of ASP.NET in the open, and it’s all available to view and contribute to on GitHub.  Even TFS supports Git repositories now and so do the other sites in the “social coding” space.

If your daily home is Windows and Visual Studio, here’s a short primer on how you can get started.

Okay, I have Visual Studio, what else do I need to install?

Right now, nothing.  Let’s start with Visual Studio’s capabilities and move on from there.

At the Philly.Net Hands-On Lab last September, I demonstrated a few tools by using a GitHub repository.  We’ll practice cloning this repository first.

The purpose of this post, and this lab, is just to show you how to use the Git tools built into Visual Studio.  As you get more advanced, there are a lot of other great things you can do with Git, and I’ll have some tips for you on that as well.

Get the URL for the repository

If you head to, you’ll find the repository.  First off, you could just use the Download ZIP button in the lower right to get the code.  But instead, copy the clone url.  We can use that inside Visual Studio.

The url is:

Open Team Explorer in Visual Studio 2013

You can use any Visual Studio edition to do this.  Whether you have Ultimate, Professional, Community or an Express Edition, this works.  Since this project is an ASP.NET Web API project, you COULD use Visual Studio 2013 Express for Web.

But don’t do that.  If you need a free version of Visual Studio, get Visual Studio Community.  It is equivalent to the Professional version, but it is absolutely free for you to use to get started learning to code.  Get it here.  Do not bother with the Express editions anymore.  It is high time they were unified again and kudos to Microsoft for doing it.

Once you’ve opened Visual Studio, you need to open Team Explorer.  By default, this is one of the tabs exposed on the right side, by the Solution Explorer and Properties tabs.  But let’s say you’ve closed this tab.  You can also open it by going to the View menu or if you insist you can use the handy key chord “shortcut”: Ctrl+\, Ctrl+M.

Okay, so Team Explorer is staring at you.  Click the Home icon to get the Home panel, then click Settings.


You can ignore any messaging or warnings about installing third party Git tools for now.

Fill out your Git settings

Even though it’s not strictly necessary right now, it’s a good idea to get this out of the way.  In the Settings panel, just click Git Settings to get this view:


I recommend filling your name, email address, and select a default folder where you want cloned repositories to go.  You can also enable downloading author images from third party sources, which is a really long-winded way of saying: “When you clone from GitHub or Visual Studio Online or somewhere else, get the pictures for the code authors to show in the source history.”  Most code repository sites use a Gravatar.  A Gravatar is just an image linked to your email address, and the folks at maintain a repository of these.  You could look up my Gravatar profile here.

(Oh and for that default source location.  I switched to using C:\Source.  I like keeping my stuff in my Users folder so backing up my data is easy, but it can be nice to have your code in an easy to reach place, especially when you use command line tools on it).

Clone a repository

Click the icon that looks like a plug to open the Connect panel.


In the Local Git Repostories section, click Clone.  In the top edit box that turns yellow, paste in GitHub’s clone url (  Visual Studio picks a location for this repository based on the settings you entered a moment ago.

Click the Clone button.


You can see above on the left that Visual Studio uses Git to clone the repository locally and lets you know when it’s done.  This is a small repository so it should clone pretty quickly.

Now double-click the new PdnJsToolsHol repository to go to the Home panel (or right-click it and select Open). You want to do this instead of just clicking the Home icon because you want this repository to be put “in context” so you can work with it.  You’ll notice the repository “in context” is listed in the view below.


From here, we can view changes you’ve made that you haven’t committed yet.  You can click Changes to view code you’ve modified but haven’t committed to your local repository, yet.  You can click Branches to view the branches in your repository, create new ones, or merge one of the branches into another.  You can click Unsynced Commits to see what you’ve committed but have not pushed back up to the repository you cloned from OR what has changed in that repository that you haven’t pulled, yet.

Now that you put this repository “in context” you could use the Home button to get back here.

View project history

To get your feet wet, let’s look at the commit history for the branch you cloned (the master branch).  Click Branches and you should see the only Published Branch is “master”.  Right-click on it and choose “View History…”.  As you see below, you can see the commit history for the branch you cloned.


Let’s make a change

After all this work we’ve done, if you look at Solution Explorer, you may still see no solution loaded.  We cloned a repository but we didn’t actually open a Visual Studio solution!  Some repositories have many solutions, but this simple repository just has one.  You could easily go out to find it in the file system wherever you chose to put your GitHub repositories.  But Team Explorer will find it, too.

Go back to the Home panel for this repository by clicking the Home button.  We didn’t pay attention to the bottom of this panel where the Solutions in the repository are listed.  Just double-click to open the solution.


In Solution Explorer, you can see the familiar source control icons next to files if you’re used to connecting to TFS projects or even another source control solution like SubVersion.  I’m making a quick edit to Index.html to change the banner from Philly.Net to  The point of the post isn’t to concentrate on code, so you can make ANY change you want.  Add functionality, or just a comment.  Just change something.

Committing to your local repository

Back in Team Explorer, open the Changes panel.  If you’re lost, click the Home button and then click the Changes button.  From here, you will see that your change(s) are detected and you can just enter a commit message and Commit it.


After committing, you can go to the Unsynced Commits panel and click the Sync button.  Note that besides Syncing (both pulling changes from the remote repository you cloned from AND pushing your changes to that repository) you can just select Push or Pull.  Except in this case, you can’t push to my repository on GitHub.

Try clicking that sync button and you’ll see something like this:


To commit directly to my repository, I have to give you permission.  And this doesn’t scale very well.  Especially in very visible, large open source projects, there really isn’t the time or ability to evaluate everyone who says they want permission to merge into your repository.  It just doesn’t make sense.  There has to be another way to do this.  And there is… it’s the pull request.  However, before you can submit pull requests, I’m going to have to show you how to fork the repository on GitHub first before you clone it.

Okay, so far you just showed me how to work with my own code

So everything, I’ve shown you so far will help you get started with GitHub, Visual Studio Online, or any other service using Git that you can just grab a clone url from.  Before I show you how you CAN contribute to my sample repository on GitHub, let’s go over how you can start using a git version control service today with your own code:

1) Get an account at GitHub (This advice will work the same for Visual Studio Online,, etc).

2) Create a repository using the tools on the GitHub web site (I find this MUCH easier than starting locally)

3) Clone the new, empty repository

4) Copy your code into this location on your local drive

5) Consider adding a .gitignore file so you don’t have to deal with files you DON’T want committed (.suo files, bin folders, obj folders).  My repository has a sample you could get started with.

6) Commit locally and sync back to your new repository.

All right, I’m ready to contribute!

Okay, let’s go a step further.  I want you to send me a pull request changing something in my repository. (While I do not expect this to happen, if this post goes viral, I may not get to your pull request quickly).  It’s helpful to go through the process to understand the value proposition of using Git, and to understand that there is more to it than just being the hot new thing.

The key is how easy Git makes it for you to fork repositories you want to contribute to and work on it in isolation, freeing yourself to commit your progress as much as you want and SHARING that progress with interested friends or team members without EVER touching the master repository.

1) Fork the repository.  GitHub creates a repository you control, so you can sync to it however you like.

2) I strongly recommend creating a branch (like a feature branch) for the code change you eventually want me (or the repository owners) to accept into the source.  Why?  Because GitHub pull requests work by comparing branches.

3) Clone the repository locally.  Switch to the branch and work.  Commit locally.  Sync when you are comfortable pushing up to your repository.

4) When your work is finished and represents the change you want the original repository to take, create a pull request.

5) Your pull request might be accepted or rejected.  GitHub has tools that allow a conversation over the pull request.  Eventually it will be closed.

6) Common etiquette (or sanity) is to delete your feature branch when the pull request is closed.  You don’t want to use it further anyways.  Got more work to do?  Start a new branch.

What’s missing from the tutorials?

Most Git or GitHub tutorials go into creating your repository, cloning it to your machine, making a few commits, and pushing them back to your repository.  There were two immediate issues I had after reading these:

1) They mostly use Git at the command line.

Fair enough.  That allows the tutorial writer to write once and everyone can follow along.  Others might complain that if you aren’t using command line you aren’t a developer, but that’s obviously just the “No True Scotsman” fallacy at work so we don’t have to pay attention to that.  What’s more important is to know what you CAN’T do outside of the command line so you can be productive in the best way that works for you.

2) It sure doesn’t feel that different from TFS, SVN, CVS… I thought Git was revolutionary?

Right! What’s the value proposition of Git if we clone a repository and push back to our master up on GitHub or Visual Studio Online?  This doesn’t feel all that different.  Why can’t I just do this with SVN or TFS?

This is why I want you to practice forking a repository, cloning it, creating a “feature branch” to work on, then committing some code to it and opening a pull request for me to accept the change.


I want to stress that this blog post was only possible BECAUSE other folks went ahead and posted Git and GitHub tutorials in the first place.  They helped me immensely, and to be honest, you could go a long way on your own right now just by following these links:

GitHub Bootcamp at the GitHub help site

How To GitHub at – The tutorial that doesn’t tell you “how to git” but “how to github”. Highly recommended.

[VIDEO] Linus Torvalds & git: Learn about why Git was designed the way it was straight from the source.

[TL; DW] Particularly, the discussion on branching starting here.

The key is how easy Git makes it for you to fork repositories you want to contribute to and work on it in isolation, freeing yourself to commit your progress as much as you want and SHARING that progress with interested friends or team members without EVER touching the master repository.

blog comments powered by Disqus