First-things-first: hopefully you are doing SOME programming outside of work. If you are, then hopefully you are using a version control system. “Why?”, you ask. Well, first because you could fall victim to human error and mess up your code, you could just want to organize your projects, you could lose a hard drive, etc – there are a lot of reasons.
Hopefully you know that you have several great and FREE alternatives:
- Microsoft: navigate to http://tfs.visualstudio.com with a Microsoft account. You can create unlimited, private repositories, for free. You can use the native check-in/check-out TFS tools – or the distributed version control system “Git”. This is where you have an offline copy of source, and then you merge it back in with the master branch. This include bug tracking and Agile project mgmt.
- BitBucket: navigate to https://bitbucket.org/repo/create, create an account and here too you create unlimited, private repositories, for free. This service uses “Git” and also supports Mercurial for a version control system. This includes a bug tracking and documentation/wiki site for your project.
- GitHub: navigate to https://github.com/, create an account. You can create unlimited, PUBLIC repositories, for free. That typically means it’s open-source. Others can view your source code and potentially branch off their own source code from yours. If you want private repositories, they charge for that. GitHub obviously supports Git, but every Git repository here is also a Subversion repository too.
So, if you just want a place to store/version software that you do outside of work – either Microsoft or BitBucket are free, extremely good options. If you want to work publicly and/or create an open source project, GitHub is the de facto standard.
Did you notice anything special? Microsoft, BitBucket, and GitHub all support Git.
What am I proposing? Well, this blog post will show how to create Git-based projects in BitBucket and in TFS – and how to use those repositories from Visual Studio 2013.
Quick background on Git:
When Git first came out a few years ago – it was all the rage because it was so simple. It just had a few command-line tools and that was it. If you didn’t like working in command-line though, it certainly got annoying typing out VERY long commands.
Meanwhile though, for Visual Studio (and Windows users, in general) there came two very big game-changers:
- A native Git client for Windows – download from: https://windows.github.com/
- Visual Studio 2013 and later natively support Git from within the IDE
So – how does all of this work? Well, for this blog post, I’ll just cover the easiest possible scenario. I’ll stay in Visual Studio for the whole thing.
STEP 1A: Create a new BitBucket.org Git repository
For this example, I am already logged in and I navigate to: https://bitbucket.org/repo/create and fill out the form, thusly
Note that I chose “Git” as the repository type. When I click “Create Repository”, I’m brought to the home page of the repository. I note that the URL in this particular case is: https://bitbucket.org/RobSeder/division42.sampleviabitbucket – we are going to need that later.
STEP 1B: Create a new TFS Git repository
For this example, I am already logged in and I navigate to: https://%5BYourNameHere%5D.visualstudio.com and click he “New” link under projects:
Then, I fill out the form thusly:
Note that I’m choosing Git as the version control provider. Once I create the project, it brings me to the project home page and I note that in this particular case, the URL is: https://robseder.visualstudio.com/DefaultCollection/_git/Division42.SampleViaTfsGit – we are going to need that later.
STEP 2: Pull down a copy of the repository (clone)
Here is the most interesting part… Visual Studio natively supports Git now, so it doesn’t matter where your project is hosted. If it’s a Git repository, we can use it from Visual Studio.
To start, in Visual Studio (2013 or later), go into the Team Explorer window, and make sure you are on the “Connect” view. Under “Local Git Repositories”, choose “Clone”:
For the BitBucket example from above, I’d use values like this:
it prompts me for credentials – I use my credentials from BitBucket.org
and voila, I now have a local clone of that repository:
Similarly, to do the same for the TFS-hosted Git repository, we do the same thing, but use the TFS URL:
and voila, I now have a local clone of this other Git repository, hosted in the Team Foundation Service:
STEP 3: Add your code
As a matter of convention, your source code doesn’t typically go right in the root of the repository. Convention dictates that you’d typically have a docs, bin, and src folder. So, I create an src folder and create a new project under it:
similarly, for the TFS project, I do the same thing in that directory and create that 2nd project:
STEP 4: Commit your changes (push them to the server)
Here, is the next beautiful thing. Visual Studio already understands that this solution/project(s) are under source control. First, note the little “Pending add” icons next to all the files. This signifies that these are ready to be added to source control:
We’ve created an src directory, then created a Visual Studio solution and project. It’s time to upload, or “commit” the changes and “push” these to our source control repository up on the server. The quickest way to do that is to right-click the solution and choose “Commit”:
This brings up the Team Explorer window with the Changes section enabled. There are several important things to note on this screen:
First, ALL commits must include a comment. Typically, you’d just note what the major changes are they you did. No need for your name, date, or initials – all of that is tracked with this changeset. Next, the “Included changes” shows you all the things it’s going to push to the repository on the server. The “Excluded changes” are files that knows about, and also knows should not be checked into source control.
The “Untracked files” is something you should look at before every commit. These are files that Visual Studio thinks it can/should ignore. It gets it right more of the time. bin, obj, unit tests results, .suo files, .vsproj.user files etc should NOT be part of source control. However, many times a new source code file you added will be there. It will look like this:
to have that be included with your changes, right-click on the file and choose “Add”. That will move it up the “Included Changes” area:
OK – now we are ready to commit, so add a comment and click the “Commit and Sync” button:
I do that because it commits the changes on my side, pushes them to the server, then pulls down anything new on the server (or verifies that what I have locally is what is on the server).
That’s it. Now the solution and project we just created should be up on the server.
Note: To do the same thing as above for the TFS/Git project, I did need to right-click on the solution and choose “Add solution to source control” first. Then, everything else was the same as above.
STEP 5: Verify the changeset
The last thing we probably want to do is verify our files are up on the server. Let’s go take a look up on BitBucket:
and what about up on TFS:
Well, hopefully you see just how easy it is to store your source code up in cloud-based version control system. Not only will you be more organized and have your source better-protected, you are also well-positioned to expand on your project. I am showing Git here, because that is the most common, and popular (at the moment) version control system.
Next, all of these source control providers have the ability to grant someone permission to the project. So, if you want to start collaborating on a project with a colleague, you can do that very easily too. As you can see, for something you get for free, and something that is this easy to do – there are many benefits.
Now you have no excuse, go get your projects up into a source control service!