Git commit messages – actually, any commit messages – are one of those things that I believe start off with the best of intentions.
That is, we tell ourselves that from the outset of a project that this time is going to be different than the last time. Whereas, the last time, our commit messages started off well but, by the end, we’re writing things like:
- Fixed some things
- Removed stuff
- Refactored the function
Sure, this is a bit facetious, but the point is that if you look at commit messages for a lot of projects, they start off far more detailed in the beginning than by the end of the project.
I’m guilty of this, too. How, then, do we stick with good commit messages (and specifically, good Git commit messages, since so many open source developers use that service)?
Git Commit Messages
And it’s funny because the subtitle of that site is:
Don’t let your friends dump git logs into CHANGELOGs™
There are some really good ideas and conventions that to adopt from that site. (And I’ve been using them for a recent client project.) But I’m not entirely sold on the idea that Git commit messages can’t be changelogs.
But that idea is predicated on the idea that we can write good Git commit messages. And that’s where this site comes into the picture.
How to Write a Git Commit Message outlines how to write good Git commit messages by following a simple formula:
If applied, this commit will your subject line here.
There’s a little more to it all of which are on the site:
Even if you don’t spend any time reviewing the site, at least consider adopting the convention mentioned above. It does help when writing meaningful messages.
I think this convention is one any source control system can adopt, but it works especially well with Git because of how it bundles its changesets.
At any rate, even if using Git commit messages is not a good idea for changelogs, it’s still something that makes sense to have good commit messages for changesets, project history, and so on.