Programmer Musings

Git for the Solo Programmer

Despite the press in recent years asserting the software development is always a team activity, there are still individual programmers building software without help from others. I've recently had a question from one such individual asking if version control makes sense for a developer working alone.

Despite working in teams for years, I also work on quite a few solo projects. In the past, I always added projects to version control (whichever system I was using) once it reached a certain size or level of complexity. Any time I started to worry a little about a change that I might not be able to back out, I would stick the code into version control.

And so it begins...

A few years ago, I started using git. While I am still not a complete believer in the git way, there's one feature of git that has caused me to convert all of my current home projects: it is extremely easy to set up a git repository. It's so easy, in fact, that there's no reason not to.

But, Why?

For those that have never used version control on a small project (or at all), I can almost hear your question. Why bother? What does version control in general and git in specific do for you?

Ad hoc version control

If you haven't used a VCS before, you've probably dealt with changes to your software in one of a very few ways:

• There's always one version of the code in one directory.
• There may be one (or more) extra copies on your system that you are experimenting with or trying to keep pristine.
• Every now and then, you zip (or tar) all of the code and store it somewhere so you can recover if something goes wrong.

These approached can work on very small projects that don't change much. But, if you hand a copy of the project to someone else or need to make extensive changes at some point, these approaches are much harder.

Since git is going to add steps to your workflow, it really needs to provide some benefit to offset the cost.

Didn't it used to do that?

The first thing that it gives you is the ability to look at earlier versions of the project. All of us have had the problem where a tool we use all the time used to work and now it doesn't. It's sometimes hard to tell what change caused the problem. Using git, we can look back to see when something changed. If you write good commit messages when you make changes, you'll know why it changed.

Which version did I give to Fred?

The second thing you get is the ability to name particular points in development. Any time you have a specific version of the code that you want to be able to retrieve at some point, you can add a tag with git. For example, I'm using the program on my main system and I want to copy a version to my other computer. Setting a tag at that point is probably a good idea. Another point would be when I give a copy of the project to someone else for some reason. A really good reason for a tag is right before I make a big change. I'm going to change the program from using a text file to using SQLite. I'm upgrading the script to work on a new version of the OS I use. Any of these changes might break the project and I want to be able to get back easily.

I've got a cool new approach

The third thing you get is a freedom to experiment. It took me a few years to really grok the wonderful feature that this is. Let's say you think you can make your project much faster by changing some fundamental part of the design: different libraries, new algorithm, an all-nighter doing micro-optimizations. Before you make any changes, create a branch with git. Now you can make all of the changes you want over as much time as you want and the original is still safe on the master branch. If you decide this was a bad idea and you don't want to continue, throw the branch away. If you need to fix a bug on the real code even though you aren't finished with the experiment, change branch to master, commit, and come back. When you eventually get everything the way you want, merge the branches and life is good.

It's Part Mental

It's really hard to convince people how much version control does to reduce mental stress. If the project is something you rely on, every change brings a small worry that you might break something, or you might lose something that you wanted. This worry adds some mental stress the whole time you are making changes. Depending on the change, the worry may continue after you finish. There's that did I really test everything feeling.

Also, if you have multiple copies of the project you'll always be wondering which copies are up to date and which are not.

Using version control can relieve this stress. Amusingly, many of the people I have talked to that made this transition really didn't think of it in these terms. They were just happier with their work.

The ability to do experiments cannot be over-emphasized, though. It's amazingly liberating to be able to try hare-brained ideas without messing up your normal code, and have an easy way to go forward or back depending on how things turned out.