Check In Often

As a developer, you should be using source control. You should probably be using distributed source control. And you should check in, probably more often than you think.

Show Notes

No matter what specific tool you use for source control, you should be checking in your code to a source control repository. Right now, do you have code that you're working on (or were recently working on) that isn't checked in? How long ago did you check it out? If it's been more than a few hours, that's probably too long to go without checking in your work.

Why should you commit often?

The more often you commit your code to a central repository, the sooner you'll discover integration issues. This works best if you're using continuous integration, which we'll talk about later, but even without it, someone else on your team may discover an issue with your code sooner if it's checked in somewhere they can get to it sooner.

Committing is like ctrl-S.

If you grew up using word processors like Word, you've probably developed the muscle memory of hitting ctrl-S to save frequently. All it takes is for your machine or application to crash one time while you have hours of unsaved work for you to realize that you really should be saving all the time. The more often you commit your code (and ideally, push changes off your local machine), the better off you are if the unthinkable happens to your machine.

Recovering from dead ends.

Of course, an even more common use for frequent commits is that they let you jump back in time when you find that you've gone down a bad path. This, in turn, can give you more confidence to try different approaches to problems or more ambitious refactorings, because you know you can easily jump back to a known good state at any point. One of my favorite sayings is a Turkish proverb, "No matter how far down the wrong path you've gone, turn back now." When you have an easy restore point to jump to, this is easy. When you don't, it can be tempting to keep fighting with an approach you know in your heart isn't great, simply because going backward is going to be at least as painful as struggling forward.

Don't use folders for version control.

Avoid the urge to use copy folder versioning. You know what I'm talking about. That copy of the code folder you made that appends today's date to it, that's sitting next to a dozen similarly named folders. That's not source control, it's undisciplined and sloppy. That's not to say I'm not guilty of doing it myself (this approach still gives me confidence when updating production code on a live server, for instance). But if you're regularly using source control properly, you won't find the need to do this in your local dev environment.

When should you commit?

You should be committing your code whenever you've made some tangible progress. Fixing a bug, adding a test or two, implementing a feature, completing a refactoring, cleaning up a bunch of formatting issues. Each of these could easily be represented as a single commit. Now, whether or not all of these end up in your commit history after you merge your changes into the master branch is another question. But while you're actively working locally, it can certainly be useful to have this granular of a commit history available to you.

Commits are like game history

If you’ve ever played a video game that allowed saving checkpoints, you understand the value of frequently saving your progress. If you don’t, and something comes along and kills you, you’ll have to repeat a lot of effort to get back to where you were. Frequent commits in your code will save you from the unexpected just like frequent saves in your games do.

Show Resources and Links

The Copy Folder Versioning Anti-Pattern
Blog Post: Check In Often

Gospel-Centered Unity