WHY VERSION CONTROL IS IMPORTANT FOR SOLO DEVELOPERS

WHY VERSION CONTROL IS IMPORTANT FOR SOLO DEVELOPERS

http://www.cimgf.com/2009/11/07/why-version-control-is-important-for-solo-developers/

It’s common practice for any software project with multiple coders to use some version control mechanism. CVS or Subversion used to be popular. These days distributed systems like git and Mercurial are the quickly replacing the old standards. But what about the cases when you’re the only coder? Let me tell you. Whatever the initial setup cost, coding is much easier with version control than without it.

Firstly, if you think that you only work with yourself and you can handle yourself, have a quick look at the I Am A Moron section of this post or this recent tweet by Kevin Hoctor.

Now a few years ago, I started work on a helpdesk ticketing system called tina. In the early days of tina development, I’d didn’t use any version control. I was frequently confused by my own code. I’d look at a piece of code and wonder, “What was I trying to do here?” or “When did I change this? Wait, did I change this?”. Occasionally, I’d tar-up my code for a historical record and I’m not sure now if I ever referred to those tarballs. When I eventually put the tina code into a Subversion repository I was much happier because of it.

With another project, that I wanted to put under version control, I found I had no less that 3 different versions of the code lying around on my hard drive. It look some investigation with diff in order to find out which one was the most current. Fortunately I didn’t have some files more recent in one copy and others more recent in another copy, but that could have easily happened.

With version control, it’s easy to find out what changed in my code, especially if I write useful commit messages. The most unexpected (and incredibly positive) side effect was that once I started using version control, the quality of my code went up dramatically. By tracking exactly what was changing between revisions, unwanted changes and debug code did not slip into the shipping code.

It’s worth noting that this approach goes hand-in-hand with unit testing. Version control lets you know what is changing and unit testing lets you know that your changes don’t result in regressions. As solo developers without QA teams or even a QA person, using these best practices seriously improves our ability to complete with larger organizations.

So, I recommend version control for any coding project bigger than a few lines of code. I used Subversion for a while and have now moved onto git.

My tips for version control success:

1. Make small commits – don’t commit a whole day’s work if you wrote 2 features and fixed 8 bugs. That should be at least 10 commits. For sure, commit every-time you complete something – a bugfix, a feature, fixing a typo, a formatting change. It’s makes it much easier to find regressions and other issues later. Oh, and try not to work on many things at once especially if the changes overlap in the code.
2. Compile before commit – each commit represents a known state of your code, so make sure the code compiles correctly without warnings or errors before committing.
3. Diff before commit – before each commit, look over the diff of your current code compared with the last commit. Then you’ll know for sure what you are committing. If you don’t like part of the proposed commit, change it, diff it again, repeat until you like it and then commit.
4. Write useful messages – When you commit a message is required is usually. Make sure it makes sense to you and to others looking at your repository.