Jul 28, 2019 · ⏱ 2 minutes

Boost Your Team's DX By Formatting All Git Commits 🔭

Imagine the following: You've just completed a polished new feature, upgraded some dependencies, found some code paths that needed refactoring and worked on several other things you're about to release. Unfortunately, your existing commit messages look something like the following:

$ git log
Commit 453a620131169ed327d8d35ba4952ba5

  added cool feature

Commit 816d07ab563e79baa8870cc2fc587e7e

  why does this still fail 😭

Commit e1df585bf90138faac07b9f6ab8dea26

  added a lot of fixes, it also works now

Commit 03eed300b88f0191a5448d36e1f2671d

  okay, it still breaks but I updated the deps

This commit formatting will neither look good in generated release notes, nor will you be able to automate anything based on it. Chances are, that not only your coworkers but even yourself would struggle to identify changes made solely by looking at the commits.

What I'm proposing here is really simple: Let's use one of the most common commit formats used at the moment. Say you've added a new billing method to your project's backend. In this case, your commit message could look roughly like the following: feat(billing): add xyz to payment methods.

Throughout the years, I've personally shifted the style of my commits, going from the example above (which is pretty close to reality) to a standardized format originating from Angular and picked up by many open source projects and more importantly supported by a lot of tools. Not only does this enable me to quickly grasp what I committed previously, but I can utilize convenient tools for generating formatted changelogs, automating robust CI and release systems, and other use cases.

To pull in some real-life experience: At GraphCMS, we've been using standardized commit formatting for quite some time now and it's been a great way to build tooling around it, increasing the transparency of changes made and making releases less risky overall.

Of course, you shouldn't be forced into using a specific convention, in fact, most tools allow to customize commit formats freely so you're never locked in (yes, that includes emoji-based commits 🤩). The only thing to keep in mind is to go with one option and rarely if at all, change this style so your efforts won't be lost.

Perhaps this whole story sounds completely obvious to you, that's great! There are, however, still many projects out there, that haven't enforced these guidelines, making attempts to push said things forward ever so important! If you're contributing to one of those projects, please think of the benefits and be the one to bring it up 🚀

If you went through similar changes in your developer workflows and would like to share your story, please don't hesitate to jump in my DM's or send a mail!

By the way, I just set up my new Twitter account, if you have any questions or want to drop a like, just head over there.