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 Not long ago, I shared a resource that @Rarst shared with me that provides some really good guidelines when keeping a changelog. 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
Share This