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?
Top comments (8)
Don't worry too much about your commit message while you work and commit often. Finish up your work and rebase --interactive to put your work and messages together.
I do suggest breaking commits for unrelated things so they can be grouped when rebase is run.
Eh, I disagree. It helps me a lot because it makes me try to tackle one problem at a time. Without it I can easily go off the rails. And as a lead developer, I'm trying to set good examples for others on my team who currently have commits that say things like "fix it" and "make it better." I'd rather work that way from the start than be met with a complex rebasing after the fact 😊
I just found this answer and also support Jesse Philips way. I feel your argument of being lead developer and setting good examples, but one good example for me is trying to be much more productive than my colleagues.
If you care too much about commit messages in the first place, you'll end up spending time on details that don't matter at all (or even worse: start thinking about wether you should commit now or not. Spoiler: The answer is always yes ;-) ).
Maybe we use a different strategies, but I tend to commit like at least 10 times+ an hour. There are some commits like
and so on. The commit messages don't matter, as long as I know where to go back if something goes terribly wrong.
That way I don't spent much time on thinking about fancy commit messages, don't lose much work if I somewhen really need to take a step back (6 Minutes or something? Whatever...) and can take some time for the "nice" commit message when the actual PR will be transmitted.
I do think that committing too frequently can be a problem. Vim is my version control before I make a stamp, but it only does one file.
What is the downside of commiting too frequently in your opinion?
When a change is "trivially small" (a rarity), leaving just a commit title without additional detail works just as well of course. Adding the extra detail on somewhat larger commits helps me understand what I just did by recapping, and may also help another developer spelunking in the commit history someday. In terms of productivity I don't find myself spending a great deal of time on it...it's just jotting notes :)
Too mutch shuffling between different attempts could lead to difficulty in navigation the different attempts.
I reference vim because, like emacs, it has undo trees. Vim has a decent concept of an edit. If I extrapolate vims edits to commits I would find the history to be invaluable.
Git commit --fixup HEAD~3
Git commit --fixup ":/less wonky"
thoughtbot.com/blog/autosquashing-...
Git is a Communication tool
Jesse Phillips