This article doesn’t add any real insight to what’s already been said before in many other places. In fact, over half of it consists of verbatim quotes, most of which (the commit messages) aren’t even relevant as anything more than examples. The other half is an ad-hoc grammar lesson that’s only tangentially relevant.
Ultimately, the article doesn’t even have a real argument beyond “oh, here are some ways that people write commit messages; they’re all good!”
This is true. That being said bad commit messages are my #1 pet peeve. If this article gets people to try even a little harder, I call it a win.
I’m a big fan of having a template for commit messages for your open source project. As an example, finagle and netty both have templates, and it makes it much easier to understand the purpose of a commit, and then also how it achieved the purpose, which is what we typically want out of the commit message.
The only thing I’m undecided about is tagging as a prefix for the title. Examples:
Refactor: moves foo into bar
Frontend: handle frobnicator requests
I like to tag when I have a large(ish) commit series that spans multiple modules. It helps me (and others) identify at a glance which commit is modifying what. Though this approach only makes sense if you have embraced micro-commits.
That said, I don’t think I would ever tag something as ‘refactor’. To me that’s just something that should be in the message itself.
I sort of disagree that this should be personal preference - Git itself, as well as many prominent figures all advocate for imperative. Seeing as this is already relatively standard, I don’t see any benefit in taking other approaches. In order to be convinced that another approach is better, I’d have to be convinced that the benefits are worth doing something non-standard, which I think is unlikely for the vast majority of projects.
Like most style-guide things, I didn’t like it at first, but stockholm syndrome has set in and it’s all good now :P