Better Git Commits
Better Git Commit Messages
Lately I’ve been looking to better improve my own git repos, make them tidier, easier to digest and just better looking over all.
One of the better ways I’ve managed to deal with all three of these at once is with a quick change to the way I handle commit messages.
Let’s look at the way I used to do it during commit messages, it wasn’t pretty.
Requirements Needed
In making things better not just for myself but also for others I decided to look around for better examples of commit messages. My basic requirements for just the commit messages were as follows:
- Easy to read
- Quick to create
- No installing of 3rd party packages
- Cover details such as fix type and scope
Super basic but still important in my books.
This led me down a bit of a rabbit hole of Medium posts, blog posts, forum threads, Reddit posts, talking with our devs and just, finding random articles all over the place.
One such article led me to a repo for commitlint. It’s a terminal project that creates really well defined commit messages and turns them into changelogs. I liked the way they structured their commit messages but there was one small issue: it didn’t fit one of my criteria.
I continued my search and came across another project that used a similar structure, it was manual, it was structured and used the same style as commitlint. It seemed like a good fit.
Karma. They created a really neat project that allows developers to run test units on their JS code within multiple browsers quickly. They also have really good documentation, right down to commit messages.
New Commit Message Structure
Basing my commit messages on their documentation has shaped up to be a really good start and change to tidying up my own commits. The basic structure is below:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
This format lets you set a type of commit, the scope of it, the subject (the fix), lets you add further details and add a fix issue number at the bottom for reference. You can find specifics of their suggested usage within the doc pages.
New Commits
Putting these changes into place we can see much clearer commit messages, it reads better, clearer detials as to what has been fixed.
Moving forward I’ll be continuing to use this format, not just in commits but PRs as well, till I find something better!