If you write more than 10 lines of code, your source code should be in a version control system (a.k.a source control). This especially includes projects you work on outside of work. Both http://tfs.visualstudio.com and http://www.bitbucket.org both offer free, unlimited repositories – so there is no excuse!
Now, for simple projects, simple version control works fine. However, what about when you have two or more developers? How do you manage check-in’s and check-out’s so that you don’t accidentally write over each others changes?
Centralized vs Distributed Version Control:
There are countless websites, blogs, and books dedicated to this topic, so I wouldn’t re-invent the wheel. However, if you are not familiar, I found this pretty good summary on stackoverflow which covers the basics, and the pros/cons of each:
So, with a centralized VCS, it might be common for a developer to “check out” a file while working on it. Meanwhile, the other developer wouldn’t be able to modify that file until the first developer checked it in. What always happens? It’s 4:45pm on a Friday and you realize your co-worker didn’t check in those files, and he already left for the day – so you are dead-in-the-water!!
There must be a better way, right? Well, some centralized version control systems have ways to do branching and pathing, but it’s complicated and can be difficult to set up. If you use something like Git – it’s pretty simple, and it’s something you can do without ever leaving visual studio!
Using Git with multiple developers:
The darling of the distributed version control systems, at the moment, is git. It’s everywhere. Even TFS – which was already a version control system, now also supports git! Since git is distributed, that means that I will have a local repository. When I’m done with my changes, I commit my changes to my local repository, and then sync it with the main branch repository on the server. So, you make all your changes locally. Once everything is how you want it, you sync that to the server.
With one branch and when you have multiple users, this turns into a bit of a mess because several people might have made (typically tiny) changes to a file. You must reconcile those changes before you can deliver your changes. Ugh – there must be a better way, right?
Yes, there is! You can simply come up with a branching strategy. The simplest and easy one to adopt is something like this:
You have a main, or master branch – there is where your “real”, committed code is. Each developer has their own branch. Their branches came from, and can only merge-to, the master branch. This allows developers to work work offline in their own world, and then merge in their changes later.
As you can see from the diagram above:
- If the master branch hasn’t changed, you can just merge and push your changes to master. (simple)
- If the master branch has changed, and you don’t have anything new, you can just pull the latest and merge with your old code. (simple)
- If the master branch has changed, and you DO have new code, you must first merge the master branch with your code, on YOUR branch. Work out whatever problems come up. All the while, the master branch still has good, working code. Once you’ve merged master in with your code, you can then merge your code, and push your changes from your branch, out to master.
The end-result being that:
- The master branch always has the latest, known-good, working code – and it it always builds. If master has a broken build, everyone stops to fix it.
- The developer is responsible for merging changes FROM master to their code, then merging/pushing their modified code out to master.
There are far more complicated ways to set this up, but for most cases, this will at least get it so the developers are not stepping on each others code!
How do you do this in Visual Studio?
The most difficult thing here is to understand the concept. Once you get the concept, then it’s just a matter of finding the right menus. In the case of VS2013 and Git, you do all of this in Team Explorer.
To create your developer branch (and you’d have one on each machine where you develop), go into “branches”:
from here you can choose to create a new branch:
and you can call it whatever you like. To keep things simple, I like FirstLast name – or potentially an identifier. For example: JohnDoe on your main workstation, JohnDoeLaptop on your laptop and JohnDoeMac on your Mac OS Xamarin setup.
Another important thing here is you want this branch to be based-on, and inextricably joined to the master branch. Click “Create Branch”. Then you will see this is an “Unpublished branch” – you can right-click it and publish it. This means that you want to make a server-side copy of this branch, which can ultimately be merged back in with master:
At that point, it’s a matter of going between Changes, to commit what you’ve done, and Unsynced Commits to sync the latest changes.
Using your branch, going forward:
All of the above, you just have to do once per workstation, per project. Once it’s setup, to use this, there are a couple of key things…
As you settle in to start coding, stop and make sure that the correct branch is selected. The changes you make to the VS solution will be affiliated with this branch you have selected! By default, it will be master, and instead, it should be your personal, development branch.
then, code as your normally would. When you are ready to push everything to the server, go back to the Changes screen, make sure you are on your branch, and commit the changes.
At this point, go back to Branches and choose “Merge”:
In this case, we are pushing our local changes and merging with master. So, we’ve successfully synced our local branch with our local copy of the master branch. Now, we need to push this merge/commit up to the server. Go to “Unsynced commits” and click sync:
Note here that what you are syncing is the commit that we did a minute ago. That’s all there is to it.
If there are unsynced commits in main, simply go the Branches window and merge master to your branch, and deal with any merge conflicts. If everything goes fine, then you are good to continue coding, and you can redo the technique above to re-push out your latest changes.