I'm a creature of habit. I tend to configure things the way I like them, lock that in, and hunker down into the little ecosystem I've made for myself forevermore. When something arises and begins causing friction, my only hope of adapting effectively is to find a new configuration that I can quickly cut over to.

For some time, I've made git commits using a command you're probably used to seeing:

$ git commit --all --message 'Make the code less wonky'

This works alright, but I had this undercurrent of unease about it for the last while. git allows you to specify longer descriptions by formatting your messages a certain way. When you push that commit to tools like GitHub or GitLab and open a pull request, they'll use the short description as the title and the longer description will get plugged into the pull request's description field. Providing this is a matter of strategically adding some newlines to your commit messages, but I often found myself accidentally closing the quotes on the first line of the message or just plain forgetting to provide the long-form description. This was friction.

$ git commit --all --message 'Make the code less wonky

* Fix a bug
* Add some comments
* Remove bitcoin mining malware'

GitHub also recently added a feature for making commits "on behalf of" an organization — useful if you contribute to open source as part of your day-to-day work at your company. Part of this feature involves adding even more information to the commit, with more newlines to remember:

$ git commit --all --message 'Add a bit of wonk back in

* We want those bitcoins so add the malware back
* That "bug" was a "feature" it turns out


on-behalf-of: @some-org <my.email@some.org>'

This gets pretty unruly, especially if you're trying to commit early and often (something you should do!). I really wanted to start making more descriptive commits, and wanted to have the proper attribution in open source, but this is a lot of friction. Fortunately, git provided a solution that allowed me to adapt.

You can configure git to use a template for your commits, which can be stored in a file. When you don't provide a --message argument at the command line, git will open a text editor where you can edit the commit message, pre-populated with the content of your template. I figured this could be a great way to simplify some of my workflow and prompt me to add more descriptive content to my commits. This automatic prompting is small effort but adds a bit of productivity and improves the information I communicate to others, so it's a big win.

I started by creating the template that fit the commit format to which I aspired:

Summary of change

Longer description of change


on-behalf-of: @some-org <my.name@some.org>

And then I told git to use it for the repositories I was interested in:

$ git config commit.template /path/to/commit.template

That's about it in terms of setup! But I was able to start reaping its benefits immediately; my command to invoke the commit process is shorter without the --message flag (and the message that follows), and the process of thinking about what to say about the commit is now separate, which gives me a chance to pause and think of something more valuable to say than just haaaaaands.

In case I'm feeling lazy or forgetful, the template also has my back and reminds me that adding context is good to do. It also always has the on-behalf-of commit trailer, so I barely need to think about it. Overall this has saved me a lot of cumulative time, and has made me more thoughtful about what I'm sharing and putting out there. Even on repositories where I don't have this configured (because the configuration has different requirements and I haven't gotten around to it yet), I've at least switched to always using a text editor to edit my commit messages.

So the moral of this story isn't about git. Making the "right" thing the easiest possible option is the way I can truly form habits. If you're like me, if two things are equally easy I'll flip flop on them until I drive myself up the wall, and if the "wrong" thing is easiest I'm doomed. So go out there and squeeze some productivity out of your tooling by making it work for you!

What are your best tool configuration or productivity wins?