In an earlier article (Visual Studio Source Control With Git & Visual Studio Online) we discussed how to add an existing Visual Studio to source control using Git, including syncing with a remote Git repository on Microsoft’s Visual Studio Online website.

While perhaps not as common a choice as Dreamweaver or some other tools, one can use Visual Studio to manage non-ASP.NET website projects. One reason you might want to do this is to take advantage of Visual Studio’s built-in source control features. Dreamweaver has some basic source control features as well but relies more on external tools to manage everything. There are advantages and trade-offs either way, so it really kind of comes down to personal preference.

I recently decided to create VS projects to manage some WordPress plugins and themes, and I discovered that the process for getting everything going with Git and Visual Studio Online is a bit different and not as straightforward as one might like.

Install The Git Command Line Tools

Once again, since we may have some new people in the audience, before we do anything else, let’s make sure the Git command line tools are installed. Go to the View menu and select the Team Explorer item near the top. This will open the Team Explorer view if it’s not already open. Find that window and click the Home icon from the icons at the top, then click Settings in the next screen.

Once you’re in the Settings screen, near the bottom there should be a section labeled Git, and one of the links underneath it should be Install 3rd Party Tools. Click that and follow the prompts.

How To Git ‘er Done

There are many possible variations on the whole process that will work, but there are also some things that won’t work as you might expect if you have been using source control with ASP.NET web projects or non-web projects. Through trial and error, the method presented here seems to be the easiest and quickest method I’ve found.

You’ll want to start with an empty workspace in Visual Studio, no open project or solution.

This method starts by creating a local repository. Go to the Team Explorer window (select it from the View menu if it’s not already open), then to the Connect section by clicking on the electrical plug icon, or by clicking on the section title underneath the icon bar, which will bring up a menu with choices for the different pages of the source control management.


Once you’re on the Connect page, then under Local Git Repositories, click “New” and then select the path where your project will be located. At this point that should be an empty directory.

If you want to use an existing directory with files already in it, move them to a temporary location for now, because Git won’t allow you to create a new repository in a directory that already has files in it. (No, I dunno why. Seems dumb to me too, but I’d imagine there’s some reason that hasn’t yet occured to me.)

Once you have the path selected, click the Create button.


Now that the Git repository has been created, make sure it’s selected by double-clicking it in the list.

If you had moved the files from the specified directory out to a temporary location, now is the time to move them back. If it’s an empty project so far, then I recommend creating a simple text file named something like {project}.txt (with your project name) so that we can add it to the repository and kickstart things.

Now go to the File menu and choose Open->Website. Specify the same folder where you created the new Git repository. You should get a new solution with a single project/website listed, like this:


At this point, you should save your project. Select “Close Solution” from the “File” menu. You’ll get a message asking if you want to save. Save the solution file to the same folder where you created the new Git repository. You’ll probably want to also set the solution filename to “{project}.sln” or something else that makes more sense than “localhost_42341” or whatever other random name was created by Visual Studio.

Saving the solution file to the repository folder is important. If you save to a different folder, then the solution file itself won’t be able to be added to the source control project. That would be bad.

Once the solution has been saved and closed, reopen it. In the Solution Explorer, note the little plus signs next to the filenames. This indicates that the file will be added to source control with the next commit operation. However, since we just added an entire project, there may be files in the list that we didn’t want to include, so we’ll want to review everything and remove anything we don’t want to include.

Go to the Team Explorer window again, and click where it says “Connect”. A popup menu will appear. Select “Changes“.


At this point you’ll see that the “Included Changes” section includes all of the files in the project directory. However, there may be files that you do not want included in source control for one reason or another. Review the list of files and if you see anything that should not be included, click on it and drag it down to the “Untracked Files” section at the bottom. You can use control-click or shift-click to select multiple items at once before dragging them.

Now we’re ready to make our first commit to the repository. Scroll back to the top of the window and click in the yellow edit box where it says “Enter a commit message”. Enter something relevant like “Initial check-in of project”.


Once you’ve entered your message, click the “Commit” button. If all goes properly, you’ll get a message like “Commit eeaa0e65 created locally. Sync to share your changes with the server.

Before we can sync, we need to specify the remote repository with which we’ll be syncing. If you haven’t already created the project on Visual Studio Online, now is the time. Refer to the earlier article (Visual Studio Source Control With Git & Visual Studio Online) if you need information on doing that.

Once you’ve created the remote repository you’ll need the URL. You can get this from the “Code” section of the project on the website:


Go back to Visual Studio, and click on where it says “Unsynced Commits” at the top of the Team Explorer window. Then enter the URL in the yellow box under “Publish To Remote Repository“.


Click the “Publish” button and it will start uploading your files from the local repository to the remote server. This may take awhile, depending on how many files there are and your connection speed. Eventually you should get a message telling you that the publish is completed.

Now, when you commit changed files to the local repository, you can sync to the remote server by hitting the “Sync” button after the commit operation finishes.

That’s pretty much it as far as getting everything working with source control is concerned. Have fun!

I’ve used a variety of source control systems over the years.  My first experience with source control was with the old Concurrent Versions System, aka “CVS”.  When I first started working at Atari in 1990, the programmers in the TOS operating system group (for the ST computers) were using CVS to manage the source code.  I didn’t immediately adopt it myself, however, because the CVS tools weren’t actually running natively on the Atari quite yet.  The TOS programmers were doing their builds via a TTY connection to a PDP-11 system called “Beauty” that functioned as a file server and build server.

There weren’t really any version control tools running natively on the Atari back in those days, but a few years later I transitioned to using a PC as my main machine. I tried using CVS but didn’t really care for it. Then I had a chance to try out Microsoft’s Visual SourceSafe product, and it became my main source control tool for the next several years.

After Microsoft discontinued Visual SourceSafe, I ended up using Perforce for my own source control needs for many years.  I was happy with Perforce and reasonably proficient at using it.  It worked with Windows and Mac, had a reasonable GUI front-end so I didn’t have to deal with command line tools too often.

Unfortunately, I recently lost access to the server I’d been using for a remote Perforce repository.  I was able to clone everything off before it went away, but until recently,  I hadn’t yet decided what to do about a new remote repository. I could simply run Perforce locally and periodically back it up to the cloud but I wasn’t in any big hurry so I have been experimenting with different setups for awhile.

There have been several I’ve tried that would probably work OK in most respects, but there’s just been one or two small things that I didn’t care for.  Some of the popular source code project websites like Github, SourceForge, or Microsoft’s Codeplex would be fine, except that they are aimed at open source, publicly accessible projects. I like the concept of open source in general, but I work on many projects where that decision is the client’s, not mine. One of my primary requirements is the ability to create projects with restricted access, and with most sites you either just plain can’t do that, or else you can only do it with a paid account. Paid options generally aren’t too expensive, but even $10 a month gets to be noticeable after awhile. Clearly “free” was a desirable attribute, so I have continued to look at what’s out there.

I finally found one I like.

Introducing Visual Studio Online

Microsoft has a website called Visual Studio Online that is designed to help both individual developers and development teams to get the most out of the Visual Studio development environment. One of the nice features is that after you’ve created a free account, you can manage source code projects with their Git source control repositories. Did I mention it was free?

There are other free Git repositories out there, but as previously mentioned, they’re generally aimed at open source and don’t allow private, restricted-access projects. That makes them unsuitable for many developers.  Source control projects on Microsoft’s Visual Studio Online, however, are private by default.

So far I’ve only scratched the surface of the options available with a free account, but Visual Studio Online does offer paid services as well.  If you need more than 5 users on a project or more sophisticated project management tools, they have varying plans starting at $20 per user per month.  There’s also an option that includes a subscription-based license for Visual Studio.  And like most of Microsoft’s other developer stuff, if you’ve thrown a bunch of money at them to become a MSDN subscriber, all of this is included anyway.

This post is aimed mainly at two categories of developer.  Those who haven’t used Git to manage a project before, and those who haven’t used the source control features in Visual Studio. Up until recently I was in both of those categories myself.  My previous experience with Git was mainly limited to using it to download various libraries or open source projects created by others.  I’d never really tried to use it to manage my own projects.

But, after discovering Visual Studio Online’s setup, and having switched over to Visual Studio 2013 last year, I decided to give it a try.

My first project went OK, but when I tried to do it again with another project, I came to the conclusion that I’d gotten lucky the first time around. Maybe it would have made more sense if I’d been more experienced with GIT, but I found the process somewhat confusing.  I went online and browsed around awhile looking for a tutorial, but didn’t find anything that covered the entire process from start to finish.

After banging my head against the keyboard for awhile, I eventually got it more or less figured out.  But since I’d never really found the sort of basic introduction anywhere online, I thought maybe it’d be a good topic to write about.

Install The Git Command Line Tools

Before we do anything else, let’s make sure the Git command line tools are installed.  Go to the View menu and select the Team Explorer item near the top. This will open the Team Explorer view if it’s not already open.  Find that window and click the Home icon from the icons at the top, then click Settings in the next screen.

Once you’re in the Settings screen, near the bottom there should be a section labeled Git, and one of the links underneath it should be Install 3rd Party Tools.  Click that and follow the prompts.

New Project Time

Let’s assume you already have an existing project in VS2013 that hasn’t yet been added to source control.  In the Solution Explorer window, right-click on the solution name at the top, and select “Add Solution To Source Control” from the pop-up menu.


You can also create a new project and select the Add To Source Control option at the bottom right corner of the window.


Assuming that you haven’t gone into the Visual Studio preferences and set a specific source control option, either of these steps will bring up a window asking you to select between the different options for source control.  By default if no add-ons for other systems are installed, you’ll see choices for Team Foundation Server and for Git.  As previously indicated, we’ll be using Git.


A new repository will be created in the solution directory.  You can view the available local repositories by going to the View menu and selecting Team Explorer. Then click the Connect  (electrical plug) icon.  Your new repository should be shown at the bottom of the list of Local Git Repositories.


Now you’ve created a repository for your project, but you haven’t actually added any files to it.  Let’s do that now.  But first, look at the Solution Explorer and you’ll see that some of the entries now have a little plus sign icon at the left side.  This indicates that these files are under source control and that they need to be added to the repository.

Click the Home icon, then select Changes from the window.


This will take you to the Changes screen, where you can commit changed files, or add new ones, to the repository.  You should see a list of the Included Changes, which is the list of files that are about to be added or updated, followed by Excluded Changes, which is a list of other files that Git thinks should be updated, but which won’t be, and finally at the bottom is a list of Untracked Files which are other files found in the project’s directory that are not under source control.


Note that the list of Included Changes shows “[add]” at the end of each line.  This specifies that the file is not yet contained in the repository but will be added.

Now let’s type “Initial Check-in” into the yellow edit box at the top, where it’s asking us to enter a commit message.  Every time you add or update files, you need to include a message of some sort.  Ideally this describes what the changes or additions were, so that three months from now you can figure out what happened.  Once you’ve typed in a message, the Commit button will become enabled.  Click it when you’re done.


Now at the top of the window you should see a message indicating the Commit was created.    You should also see that the plus sign icons in the Solution Explorer window have been changed to little padlock icons.  This indicates that they have been saved in the repository and no changes have been made since.

Note that it also asks you to “Sync to share your changes with the server.”  This is asking us to synchronize with a remote Git server based somewhere on the web or your local network.  If you’ve never done this before (which we haven’t in this example) then clicking it will prompt us to specify the remote server.


And that takes us to…

Visual Studio Online

This is where the connection to Visual Studio Online comes in.  If you haven’t already done so, you’ll need create an account.  (Click here).  Note that you could also enter the name of any other remote Git repository other than Visual Studio Online, but that’s what we’re using for this example.

Visual Studio Online offers a lot more than just a Git repository, by the way, so if you haven’t given it a good look, you really should.

Once you’re signed into your Visual Studio Online account, go create a new project:


This will bring up a pop-up for you to enter information about the new project.  Enter the project name and select Git as the source control method.  Note that there is an option for Process Template that will allow you to select from different development process strategies like Scrum or Agile.  This doesn’t really affect our source control situation, but it does change a few things about how Visual Studio Online otherwise helps you manage the project.  It’s something you might want to take a good look at after finishing this article.


After you create the project, select the Navigate To Project button at the bottom.  Then in the next screen, select Add Code.  This will take you to a screen with important info about the new Git repository that has just been created for your project.


The red arrow points to the URL for the repository.  This is what you need to enter as the “remote server” back in Visual Studio.  So, let’s copy that from the web browser.

Back To Visual Studio

Now we switch back to Visual Studio and paste that URL into the yellow edit field:


After you’ve pasted in the URL, click Publish and your local repository will be copied to the remote one. Note that you may be prompted to enter your login credentials for the Microsoft account you used when you signed up at Visual Studio Online.

This operation is more or less the same as issuing the following command lines from the solution folder:

git remote add origin 
git push -u origin --all

Where “xyz” is the name of your Visual Studio Online account and “pdq” is the name of the project you created in it.

After The Initial Add & Publish

Once you have added your files to your local repository and published them to the remote one, it’s fairly easy to manage things, at least as far as basic operations like adding new files, publishing updates, etc., are concerned.  Of course if you get into more advanced functions, things get more complex.

We’re not going to get into the underlying methodology of using Git’s more advanced functions in this article. If you want to look at the documentation for it, click here.

Checking out a file for changes is automatic within the Visual Studio IDE.  Simply double-click a file in the Solution Explorer as you always did.  When you’ve changed a file, the icon at the left side will change from a padlock to a red checkmark to indicate that the file is checked out locally and that changes need to be committed.

Now if you go back to the Team Explorer window and look under Changes, you’ll see that there is just one file listed under Included Changes.


Enter “minor changes” as the commit message and then click the Commit button.  It will save the change to the local repository, then give you a link to sync the changes to the remote repository.

You don’t have to sync every commit with the remote repository immediately, but it usually only takes a brief moment so unless you’re offline it’s probably a good idea. Click where it says “Sync” and it will take you to the Unsynced Commits display. Here it will show that there is one local commit awaiting a push to the remote repository. Click the Push button to synchronize the two.

Ongoing Changes & Additions

Once you have committed the changes to a file, it’s marked with the padlock icon again in Solution Explorer. It will remain that way until you open it and make changes again.  Even if you make changes using an external program, Visual Studio will notice and mark it with the red checkmark.

As you create new files within your project, they’ll initially have the little plus sign icon until you have done a Commit operation that adds them to the repository.

In Conclusion

In a future article we’ll discuss more advanced topics like creating a code branch and how to reconcile multiple versions of a file which have been changed by different users.

The Git tools within Visual Studio aren’t necessarily the most sophisticated, but they’re sufficient for most basic operations.  You can always use other popular tools for Git management such as SourceTree or the Git command line tools.  There are also a variety of extensions for Visual Studio that provide additional functionality.

Most importantly, if you’re an individual developer who hasn’t been in the habit of using source control, you really need to reconsider that idea. My guess would be that you’ve avoided it because it just seemed like too much extra work.  Easier just to ZIP up your source code directory and save it to another drive, yes?

No, not really. The tools built into Visual Studio minimize the extra work you’ll need to do, and the advantages to using a source code control system are more than worth it.  Don’t forget also that you can use the source control functions with any sort of Visual Studio project.  Even if it’s just a plain HTML website.