Write Categorized Git Commit Messages
Let’s talk about git commit messages
— no one ever
But I’m going to write an article about them. It’s actually about a way to write them which makes the commit log and Github commit history easier to read. The key is categorization. Similar commits get a specific intro. So, when you read through commit history you can easily see what was related to refactoring, tests, styles, updates, build, etc.
It’s a simple system. For each commit you have this structure:
[CATEGORY_TITLE]: your commit message . I recommend capitalizing the category so it’s more obvious. A real life example would look something like this:
The key is to give each commit a category in the beginning. The length or importance of the commit is unimportant. As the project gets larger, the consistency and ability to quickly spot what happened and where will be valuable.
Take a snippet from React’s commit history. Sure, their current way works. Over 8,000 commits have been written a non-categorized way. Looking down the page, however, it’s difficult to tell exactly what’s happening. Are the changes refactors, new code, related to tests, or something else entirely?
Here’s a history of commits with a categorized approach.
[INITIAL] — for the initial commit and set up
[ADD] — broad category for code that’s added
[UPDATE] — for small updates
[REFACTOR] — refactored code
[FIX] — fixes (e.g. typos, linter rules, broken links/imports, etc.)
[TESTS] — if you write them :)
[STYLES] — style related commits
[BUILD] — during the build process
[PRODUCTION] — production related
[WIP] — work in progress
[REMOVE] — when removing files or old, unnecessary code
You can even combine them.
That’s it. A minor change you may or may not like. It’s been nice for the projects I’ve worked on, and may benefit your workflow as well. Now go rock those commit messages.