Commits are your backup

Commits are your backup

If you are a software developer of any sort, you really should use source control.  It doesn't matter if it's for personal or professional projects (but definitely for the latter), you should be using it.  When used properly, it will give an insight into what changed where, when, and probably why. Aside from that, it's a very good way of backing up your work, in the event something goes wrong.

I recently had the misfortune of my work's HP laptop automatically downloading and installing some BIOS updates.  It tried to run the installation without prompting, and then went to a fully black screen whilst the fans tried to make it into a scale model of the Helicarrier from the Marvel Cinematic Universe

Now all I get is the screen taunting me with a "protected by HP Sure Start" message.  It's a little poorly at the moment (time of writing).

The problem is, before I left the laptop alone, I was in the middle of some development work and hadn't committed it.  Not a major piece of work, but enough that I didn't want to have to do it again.  That work may be completely lost now.

I don't completely blame HP.  I mean, they shouldn't be installing updates without me confirming them first.  And certainly shouldn't do anything which may prevent the machine from an update which could corrupt the BIOS, without first warning me and ensuring I have adequate backups in place.

No, It's my fault too.  We use an effective branching strategy where I work.  Tried and tested, and I was working on my own development branch.  Before I left the machine alone for what was going to be an indeterminate amount of time, I should have committed my code.  If I had, I could check out that branch, with all of my changes to that point, and continue.  Instead, the work needs to be done again, as well as the time taken to set up an alternative machine to do it on.

I always tell my team to commit to their local development branches frequently. I even have commits on development branches for daily, or even pre-lunch commits if I know I won't be working on the task after lunch.  I will admit that the messages I use for them aren't always useful, I have used "daily commit" or "commit for safe keeping" before.  However, these commits (and the commit message within) serve another purpose.  What if you're hit by a bus on the way home?

The Bus Factor

The bus factor is a very real consideration which should be made when working on projects with other people. A commit message for a daily commit should outline what has been completed, what is in progress, and what still needs to be done.  That way, anyone picking up the work in your absence knows exactly where they need to start, and what doesn't need to be tackled anymore.

Not only can daily, or generally regular commits save you in the event something happens to the machine you work on, it can also help your team in the event something happens to you.