Skip to contentSkip to author details

It's 2016, why aren't you using a Version Control system?

 Code  programming  version control  development

I was having lunch with some developers the other day and I asked them what version control system they were using. One of them said, "I don't use anything. I store my source code on my local drive and then copy it to the network when I make changes".

I was immediately reminded of 1996, when I used a similar system to manage the code for my websites and programs that I was working on. I have memories of the nightmare that was copying different versions to different folders named after their revision numbers. Sometimes, there would be code in one folder that wasn't in the "current" release that had to be copied over. I also remember many times where I accidentally overwrote new code with old code because I forgot to change where my editor was saving the file. I didn't have a way to restore the code, so it was lost forever.

It is 2016, there are many ways you can more safely and professionally store and maintain your code. The benefits of version control is that you can label each code check-in with a description of what the changes accomplished. You can also access earlier versions by simply checking them out. Comparing differences in the files between versions is usually built in to the version control system, so you can easily see what's changed.

I think the best benefit of a version control system is the fact that it's an instant and automatic backup of your source code should something catastrophic happen to your development environment.

I have used Microsoft Visual Source Safe (ugh, I hated how it handled file locking when someone else checked out a file), PVCS, StarTeam, Apache Subversion (SVN), Git, Visual Studio Online and Microsoft Team Foundation Server. So far, I like Git the best because of its simple nature. There are tools for Git that provide a GUI, but I believe many users of Git are terminal wonks who use the command line interface.

Here is a list of some source code control systems you can use today:

  • Git - Probably the simplest version control system to set up and use for just about any situation. It is especially suited for individual developers contributing to open source projects. It has a great mechanism for "pushing" code to a remote and creating "pull requests" that the original project maintainer can integrate into the mainline. There are also tools for Git that allow you to integrate with your IDE for a nice GUI you can use.
  • GitHub - Really just an online Git repository management system, but I feel that it is necessary to mention it. There are other online Git repository management systems, but GitHub is one of the most popular.
  • Microsoft Team Foundation Server - It provides a lot more features than just source code control. It also provides team and project management features to help you manage software project using various processes (MSF, Agile, etc.)
  • Apache Subversion (SVN) - I have used SVN before and I liked it. It lends itself to the "feature branch" approach to source code management. There is a popular Windows shell integration called Tortoise SVN that allows you to create SVN repositories by simply right-clicking a folder and using the built-in context menu that pops up. (Incidentally, there is also a Tortoise Git)
  • PVCS - UGH. That's all I have to say. I have had to use this before in a large corporate environment and I hated it.
  • Visual Studio Team Services - This is a great way to work with Microsoft tools (especially for small teams). The pricing is great. Up to 5 users is free for online storage and project management features of TFS. I have used it for personal projects with great success. It allows you to use Git or TFS for source control.

Here is a list on Wikipedia that is more inclusive.

Once you are using Source Control, a whole new world opens up. You can then set up automated builds. Once you do that, you can have your builds automatically check out code from the most recent main branch of your project. Then, you can set it up where an automatic build is launched every time someone merges code into the mainline. All of this is basically leading up to what's called Continuous Integration (CI). That also includes automated unit testing so that if a test fails, the project build does not succeed. Then, once a build is successful, you can have it automatically deploy to your different environments - test, stage, and even production (depending on how you have your approval process - and integration and user acceptance testing - set up).

This makes the overall process of software development a lot easier to manage with fewer manual processes involved. But you can't have any of it until you begin to manage your source code maturely.

Developing software without using a version control system is risky. Who is going to know what to do with your source code once you are gone? Be a good steward of your code and start using version control now.