Source Control
How do organizations maintain source code and enhance it? What if you add new members to your team, will they be able to work on your code? How will you know what version of the software you delivered to your testing staff or your clients? These questions all have to do with software version control. A variety of source control management tools exist today. With all these choices, how will you know which one fits your organization’s needs?
Lets take a few common examples and explain them in short detail: CVS, SVN, and GIT.
CVS
CVS is a source control management tool that has been around for decades. It is no longer supported, but I chose to mention it to set an evolutionary baseline. CVS offers a client/server architecture that can be installed on many legacy platforms (which is why you still can bump into it in the wild). Windows NT, Windows 95, OS/2 and VMS are all supported. You can check source in, have it timestamped and versioned, and even ‘branch’ (in a limited fashion). A ‘branch’ is source code that has been split off the main ‘trunk’ of code to be operated on separately so as not to disturb the working code line in the main ‘trunk.’ CVS is limited due to lack of continuing support, lack of directory of files support, and no one-stop versioning for associated files.
SVN
SVN came along and embodied all the same features that CVS has, and it added better versioning that allowed more than one version of code lines to co-exist simultaneously, as well as improved integrations with third-party tools. The architecture is still client/server, but the source control system was more flexible and ‘smarter’ than CVS.
Git
Git fixes some of the negative strikes associated with SVN such as speed of check-in/out, distributed (instead of client/server) architecture, and overall a much simpler toolset. Git has become the tool of choice for many in the opensource community. I am sure that some larger corporations are experimenting with this tool as well. Overall, Git is becoming readily adopted because of it’s simplicity. One note however, some have confused the tool Git with Github. Github is just one example of an online public/private repository you can use. There are many other Git enabled repositories however (bitbucket, unfuddle, etc.). The Git tool set is what you use to check code in and out of these cloud-based repositories, it is not a repository itself.
Recently it has become common practice for potential employers to ask for the location of your latest code portfolio/repo so they can see some of your work and decide if you are a good match for their organization.
One major advantage to using Git is the number of platforms and tools that are integrated with it. Zendesk is fully integrated with Git repositories so that you can ‘commit’ a change to your code along with a Zendesk ticket number and some text to be inserted into said ticket. Also, platforms like Heroku, Node.js, and Openshift also have integrations that allow instantaneous synchronization with the Git repository of your choice. Automation tools like Chef, Puppet and Ansible also integrate nicely with Git.
While more flexible and more widely adopted, Git can be a bit difficult with respect to one item; subtree checkout. There are times when you do not need to checkout an entire Git repo. You do not have a choice unfortunately. SVN does allow subtree checkout however. This one ‘feature’ is annoying in my opinion.