December 13, 2024 By Angie Herrera
Git Commit Messages
I've started writing Git Commit messages in a way that keeps things organized and makes future me a bit happier and less stressed.
Back in September, Will Browar, a fellow Craft CMS developer, posted a screenshotof his personal website’s Git commits on Mastodon. I noticed his commit messages were all prefixed by "fix", "feat", or "chore". As someone who got into Git sorta slow, still only touches the surface of Git, and whose inner nerd is always curious about what the cool kids are doing, I was intrigued. So I asked Will to tell me about it. His reply:
@angieherrera Hey Angie, a friend of mine turned me on to Conventional Commits a few years ago and it's a way to prefix commit messages to help you search and filter them later. Also, if you're pushing a lot of granular commits it's helpful as a way to essentially document all of the changes you’re making when you look back through your commit history.
I think it came out of the Angular community but I’ve gotten in the habit of doing this at work and for every project:
Will was kind enough to also explain his version of Conventional Commits. So I put that little nugget away until I could make time to dive a bit deeper into it.
When I got back around to it (which admittedly wasn’t that long after), I was instantly hooked. As someone who loves and craves organization in a lot of areas of life, it made so much sense to me. And its simplicity made it even more appealing and made me decide to implement the basics right away. With a little bit of time, I finally came upon my own interpretation for my Git commits when I’m building and maintaining websites:
- feat: anything feature related, even if deleting code or making changes to existing features
- fix: fixing a bug or issue without new feature code
- refactor: code change that neither fixes a bug nor adds a feature but somehow improves the codebase (for me this is usually streamlining CSS)
- cms: changes to the CMS (version updates or plugin updates, installs, or removals)
- build: Changes that affect the build system or external dependencies, such as npm, DDEV setup, or Laravel Mix.
There are a handful of clients that have monthly support retainers which includes regular CMS updates, fixes, and the occasional small feature add. Clients request the fixes and features on my client portal which attaches a number to it, much like GitHub Issues. For those, I add the request/issue number to the commit as well. I haven’t been super consistent with where I put the number, but I think I finally settled on this:
fix (#77): adjust portal login text and layout
There’s really not much to this. But admittedly once in a while I get stuck on whether to call something a feat
or a fix
(because I’m persnickety like that), so I refer to a note on this that I keep in Apple Notes.
Is this super groundbreaking? Nah. But it does add a nice level of organization that is especially helpful when trying to remember when you worked on a particular part of the codebase or a specific issue.