In today’s day and age of software development, there’s no excuse for not putting your source code under some form of source control. Source control (also known as “revision” or “version” control) is primarily used to make developing software in a team less of a nightmare.  And when you’re working with a team, the source control repository is usually on a server, so worst case scenario, if every team member’s computer’s hard drive fails, a new computer could still check out everything up to the last source code commit from the server and no work is lost.

But source control makes sense even when you’re not working on a team, and it makes sense even when you’re storing the repository on the same hard drive as the source code itself! (Note: you should probably always keep some sort of back-up on a different drive of any important work you’re doing.)

The first and most obvious reason for using source control, even as a solo developer, is to keep a record of what the source code you released to end users looked like.  With the proliferation of mobile devices and their app stores, its become increasingly easier for solo developers to get an application they’ve developed out into the hands of lots of users.  If you’re publishing to Apple’s app store, you can easily put in a week’s worth of work into your app between submitting your update and your update being available on the app store.  Combine this with the fact that not every one of your users is necessarily going to download every single update you push out, and it becomes pretty obvious that your source code will basically never look identical to the way it looked when you released your app to your users.  So, what happens when your users encounter a bug?

If you’re using souce control correctly, then just before you pushed an update out to any of your users, you’ve specially marked a commit (or a new branch) as a release version (and denoted the app version number with the commit).  This is important.  Once you’re able to recreate the user’s bug, there’s a really important next step: have I already fixed this bug?  Source control helps us see what changes we’ve made to a file over time.

For those who are working in teams, source control is a no-brainer already (and if you’re working in a team and not using source control, what are you doing?). The nice thing about source control is that it completely eliminates the need for lines like this:

Source control already keeps track of what user is making the change and at what time the change was made.  The user then simply leaves the explanation of the change in the commit message.  Your change documentation is now more rigidly enforced, and your actual source code has less clutter.

Finally, source control will keep track of every version of your code, and this can be helpful. Suppose we initially implement a particular algorithm to solve a problem. Then, we decide that the first algorithm has too large of a memory footprint, so we want to implement a different algorithm which is more memory efficient. Then, sometime later we change our mind again and want to go back to the first version. We forgot how to implement it. If you’ve run into this problem frequently (without source control), you’ve probably made a habit of leaving in large chunks of code commented out. This works, but it takes up a lot of space, and its there inexplicably (unless you’ve left a comment there explaining it). But more importantly, it’s hard to be sure when you can get rid of that code. But that’s the beauty of source control.

With source control, as long as we’ve made a commit that included the original algorithm, we can completely delete it from our source code and re-implement a different algorithm. We can always look back through source control. We can see every previously committed version. We never have to worry about how long a large block of commented code should remain in our source until it’s safe to remove. We can safely remove it immediately and rely on source control if we ever ned to fetch it.


Leave a Reply