A commit should not be taken lightly. A commit is a work of art, a labor of love chiseled down to the bare essentials. Think of a project repo as a novel, with each branch as a chapter, each line of code as a sentence, and each commit as a paragraph.
I don’t have a master checklist for things that must be satisfied in order to commit. It’s more a feeling. If I’m adding a new method, does it warrant tests that I have not yet written? If so, I go back and write the tests. Could some code read a little nicer? Is it clear? What will someone reviewing this code think? What would I think of this code if I were reviewing it myself? Are all of my tests passing? What will they think of me?!
And naming your commits-ah! This is even more important when you’re not only communicating with people reviewing the code now or in the future but also a client (as we tie our commits to stories). Why does this code exist? What value is it adding, in layman’s terms? What edge case is it solving? When this update hits the client’s inbox, will it raise an eyebrow or make them think I’ve got everything under control?
This is the internal dilemma many (possibly overly self-aware) developers have many times each day. I deal with the crisis with a huge helping hand from a little unmaintained OSX tool called GitX. Many git GUIs exist, but GitX has the most lightweight and intuitive interface I’ve come across. It allows me to effortlessly make line-by-line commits (and discards) which enable me to craft my commits to tell the story of what I am trying to achieve. After one of those exploratory coding sessions, it lets me go back and review and refine my work before giving it a conscious seal of approval. Always having access to a real-time diff allows me to catch countless bugs, code smells, and junk that would otherwise clutter up the project. I feel lost without it.
Making a commit is not simply saving state–it is declaring victory over the problem at hand. A long series of these small triumphs is what makes a good project.
