Day 152: Microcommits

I’ve been writing mostly personal posts for the past several days? weeks? man, how long have I been in this super obsessive coding phase? so I’m going to try to switch it up by talking about a coding practice I’ve found helpful.

A quick primer for the non-coders out there: With modern software development, everyone uses some form of version control, which lets you keep track of changes that you make to your code over time. It’s like the way that Google Docs keeps track of past revisions so that you can go back and see what changes you’ve made over time.

This is especially useful for code because bugs are inevitable and it’s useful to be able to see why you (or someone else) wrote the code a certain way, even if it took place weeks or years ago.

The way that you create this history is by making “commits” to your code. Commits are like checkpoints you declare as you develop code. Once you have your code saved at a checkpoint, it’s much easier to make significant changes because you know that you can always restore it if you change your mind later.

Okay, I thought about providing examples with code for what I’m about to talk about but (1) it’s 2:20 AM and I’m ready to go to bed (yup, another big coding day today) and (2) I forgot what my second point was because I’m tired.

I used to write commits based on significant changes, like adding a new feature. But for a while now, I’ve been trying to keep my commits super small. Microcommits.

As you jump around in a codebase, you’ll notice opportunities for refactoring or making somewhat unrelated changes to the task you originally set out to do.

It’s tempting to go ahead and make those changes, but I’ve found to valuable to make those changes separately in separate commits because those “small” changes often balloon into multi-file refactors for me. As a result, the commit ends up including not only the bug fix or the new feature, but also a bunch of other crap. It might not seem like a big deal in the moment, but it’s a real doozy when you look back on that change weeks later and try to figure out what the heck you were doing.

I use Conventional Commits / Angular’s commit message guidelines to help me keep my commits small. Having to specify what type of commit it is makes it easier to break thing apart, so that instead of my commits looking like quick fix lol, they now read fix(url): ensure urls are https.

I once saw a repo of someone devleoping a non-trivial project using exclusively emojis for commit messages, and I had a minor panic attack.

This is getting rambly and I feel like this post could have been like a single sentence and I really need to writing R2R and going to sleep so late.

Takeaway: Be kind to your future self by making tiny commits.