Why I Don't Get Romantic About Commits Until Later

As I've continued to work on bigger and bigger projects, I've found that in the early phases of a project, commits can be a blessing and a curse. When you're still in the early, discovery phases of a project (i.e., you know roughly what code to write but not exactly), I've found that frequent commits tend to be jarring.

As you work through a problem, it's likely that you will have false-positive solutions that looked right when you started, but later, you realized needed to be tossed out. While there's nothing wrong with having this stuff in your commit history (in some situations, you may want to go back and grab an old idea and tweak it), more often than not, it's better to discard/not commit that code altogether.

Daily Commits

Before figuring out exactly how things will take shape, my default solution is to roughly do daily commits. Instead of creating multiple commits throughout the day, I'll do one "close of business" commit with a multi-line commit message like this:

git add .
git commit -m "wip figuring out mobile navigation
> wip active nav item on scroll
> add lib/debounce module"

What's nice about this approach is that on the following day, I can see roughly where I left off (having a wip—work in progress—flag in my commit message essentially makes this a soft todo list). Instead of having to scroll back through multiple commits and investigate what I was doing, I have a clear understanding for what's next.

When to get serious

While the above strategy works during the "rough draft" stages of a project, eventually, it can cause headaches. Typically, I've found that the time to start doing small, single-change commits starts when you move from a purely development environment to staging or production.

At that point, you've more-or-less figured out your solutions/approach and are in the debugging stages. It's during this phase that seemingly small changes can have a big impact on the stability of the overall system. If you're not committing frequently during this time, a phantom change can trip things up leading to wasted time tracking down what introduced the issue.

A panacea? No. Good enough? you bet.

As with all approaches, a disclaimer is still in order. This isn't meant to be a religious statement. Depending on the project, there are situations where small, tidy commits from day one are more advantageous than not (e.g., writing a public-facing package/library where you know the exact approach to implementation).

But, if you have the luxury to take a less-pedantic approach early on, I've found reducing commit activity can help to increase productivity.