Over the years I’ve used many source control systems. Most of them seemed pretty simple to use after a short period of time. However they all have their idiosyncrasies that will occasionally catch you out and some of them have been next to useless at their intended purpose.
The worst of these systems I have had personal experience with was Visual SourceSafe from Microsoft, this shouldn’t be used by anyone, ever. I’ve seen it do the only thing a source control system should never do – lose your work. I must admit that all my experiences with Microsoft solutions for this particular task have been poor. I’ve only had TFS inflicted on me once and that experience was extremely lumpy and I really never want to have it again. Certainly after reading that at the core of TFS is a re-written Visual Source Safe, shudder.
There are many source control systems to choose from which can make it a bewildering decision to make. They range in price from free to eye-wateringly expensive for “corporate solutions”. Source control is source control, it either does it or it doesn’t, you can keep your bells and whistles thank you! I haven’t had the opportunity to try any of those since I haven’t worked for a massive organisation that was ever prepared to spend that kind of cash – yes they really can be THAT expensive, think six figure sums of cold hard cash, just on source control. Your product has to be worth millions before you’d even consider them.
Subversion Source Control
For the most time, including my home projects and business source control tasks I have been using Subversion, particularly SVNServer and TortoiseSVN. Since these projects are a one developer affair the extra functionality of a distributed architecture for collaboration was never a consideration and since I was also already very familiar with the system this was a no-brainer decision. Install, setup a repository, get on with code.
To be honest SVN still isn’t a terrible choice (unless your name is Linus then you are stupid and ugly by default). It does the job, it doesn’t get in my way (that often) and since everything is local to my machine it also performs well. As soon as you have to start going over the network the performance can degrade dramatically though.
Enter Git Source Control
So last year (yes I know I’m very late to the party) I had my first commercial requirement to use Git and I also started using GitHub to host some of my own projects related to my Prism articles (part1, part2) and other bits and bobs. I think one of the reasons that I had at that point kept Git at arms length was that I hadn’t been given a compelling reason to NOT carry on using Subversion. I also hadn’t been given a commercial reason to NEED to use Git, I was already busy enough writing code to start changing core elements of my workflow.
Another issue was that during my first commercial use of Git, when I hit an issue the guys who owned the repository also didn’t know how to solve the issues which wasn’t very reassuring. That just put a flag up for me hammering home that “Git was inherently complicated” – avoid. I had also struggled to get some of my own stuff up onto GitHub using their own Git client application (which I now don’t use as I don’t think it’s very good to be honest).
There was no denying the rise and rise of GitHub as a platform and the fact that all my fellow developers seemed to be flocking to Git and loving it. The final straw that led to this blog post was that I really wanted to help out on some open source projects – chiefly MvvmCross.
Now I had to learn Git and boy am I glad I did.
From the initial confusion, which is absolutely related to the way you think about source control and the choice of verbs like Add, Commit and Branch (among others), is that Git thinks very differently about these verbs. It also does very different things in response to them on the command line. BUT once you get it, you’ll realise the shortcomings of all the source control systems you’ve used before.
Git solves problems you didn’t even know you had.
The biggest difference that WILL confuse you is going from a traditional centralised repository model to Gits distributed model. Don’t assume you will just get this fact, I thought I would, I didn’t, it hurt. The best graphic I’ve seen that encapsulates this is …
Gits distributed model
The basic gist of this is that there is no one master repository that you are used to interacting with. There are many but most importantly you have both a local “working copy” and a “local master repository” or “staging area” which you commit to. You can link to an arbitrary number of “remotes” (other repositories) and push and pull from any of them as if they were all master repositories (in centralised parlance). It couldn’t be more different from something like Subversion.
In the graphic above the origin can be thought of as a traditional central repository but you can have lots of these if you want. More importantly you can also pull changes from anyone else and they can pull (update in SVN terms) from you. All very cool, and very powerful.
Switching to Git Source Control
To get started with Git you first need to install Git itself (none of the gui downloads include Git). A good GUI client (none of them are perfect) is SourceTree from Atlassian. They also provide great resources here. There is also a completely free Pro Git book.
I’m not going to go into any more details about that here as this is what the videos and links are for. All these resources and the main video above will give you some context on Git. Once you’ve watched that video this is the next one you should watch to get to grips with the nuts and bolts of Git.
Over the years I’ve used many source control systems. Most of them seemed pretty simple to use after a short period of time. However they all have their idiosyncrasies that will occasionally catch you out and some of them have been next to useless at their intended purpose.
The worst of these systems I have had personal experience with was Visual SourceSafe from Microsoft, this shouldn’t be used by anyone, ever. I’ve seen it do the only thing a source control system should never do – lose your work. I must admit that all my experiences with Microsoft solutions for this particular task have been poor. I’ve only had TFS inflicted on me once and that experience was extremely lumpy and I really never want to have it again. Certainly after reading that at the core of TFS is a re-written Visual Source Safe, shudder.
There are many source control systems to choose from which can make it a bewildering decision to make. They range in price from free to eye-wateringly expensive for “corporate solutions”. Source control is source control, it either does it or it doesn’t, you can keep your bells and whistles thank you! I haven’t had the opportunity to try any of those since I haven’t worked for a massive organisation that was ever prepared to spend that kind of cash – yes they really can be THAT expensive, think six figure sums of cold hard cash, just on source control. Your product has to be worth millions before you’d even consider them.
Subversion Source Control
For the most time, including my home projects and business source control tasks I have been using Subversion, particularly SVNServer and TortoiseSVN. Since these projects are a one developer affair the extra functionality of a distributed architecture for collaboration was never a consideration and since I was also already very familiar with the system this was a no-brainer decision. Install, setup a repository, get on with code.
To be honest SVN still isn’t a terrible choice (unless your name is Linus then you are stupid and ugly by default). It does the job, it doesn’t get in my way (that often) and since everything is local to my machine it also performs well. As soon as you have to start going over the network the performance can degrade dramatically though.
Enter Git Source Control
So last year (yes I know I’m very late to the party) I had my first commercial requirement to use Git and I also started using GitHub to host some of my own projects related to my Prism articles (part1, part2) and other bits and bobs. I think one of the reasons that I had at that point kept Git at arms length was that I hadn’t been given a compelling reason to NOT carry on using Subversion. I also hadn’t been given a commercial reason to NEED to use Git, I was already busy enough writing code to start changing core elements of my workflow.
Another issue was that during my first commercial use of Git, when I hit an issue the guys who owned the repository also didn’t know how to solve the issues which wasn’t very reassuring. That just put a flag up for me hammering home that “Git was inherently complicated” – avoid. I had also struggled to get some of my own stuff up onto GitHub using their own Git client application (which I now don’t use as I don’t think it’s very good to be honest).
There was no denying the rise and rise of GitHub as a platform and the fact that all my fellow developers seemed to be flocking to Git and loving it. The final straw that led to this blog post was that I really wanted to help out on some open source projects – chiefly MvvmCross.
From the initial confusion, which is absolutely related to the way you think about source control and the choice of verbs like Add, Commit and Branch (among others), is that Git thinks very differently about these verbs. It also does very different things in response to them on the command line. BUT once you get it, you’ll realise the shortcomings of all the source control systems you’ve used before.
The biggest difference that WILL confuse you is going from a traditional centralised repository model to Gits distributed model. Don’t assume you will just get this fact, I thought I would, I didn’t, it hurt. The best graphic I’ve seen that encapsulates this is …
Gits distributed model
The basic gist of this is that there is no one master repository that you are used to interacting with. There are many but most importantly you have both a local “working copy” and a “local master repository” or “staging area” which you commit to. You can link to an arbitrary number of “remotes” (other repositories) and push and pull from any of them as if they were all master repositories (in centralised parlance). It couldn’t be more different from something like Subversion.
In the graphic above the origin can be thought of as a traditional central repository but you can have lots of these if you want. More importantly you can also pull changes from anyone else and they can pull (update in SVN terms) from you. All very cool, and very powerful.
Switching to Git Source Control
To get started with Git you first need to install Git itself (none of the gui downloads include Git). A good GUI client (none of them are perfect) is SourceTree from Atlassian. They also provide great resources here. There is also a completely free Pro Git book.
I’m not going to go into any more details about that here as this is what the videos and links are for. All these resources and the main video above will give you some context on Git. Once you’ve watched that video this is the next one you should watch to get to grips with the nuts and bolts of Git.