As a software engineer, attention to detail is key because one small typo in your code can cause catastrophic bugs. Code isn't the only artefact software engineers produce, though. For example, most of us create numerous commits every day. Each commit includes a commit message describing the changes. I argue the same attention to detail that is necessary to write high quality code should be extended to many other things a software engineer does, including writing commit messages.

Investing the small amount of time necessary to write great commit messages brings many benefits. The reason is simple: a good software development process is all about communication. Commit messages can communicate intent and motivations which can't be deduced from the code changes.

Going a step further, defining rules about the way commit messages have to be written allows programmatic processing. For example, changelogs and semantic versioning can be automated. Furthermore, a consistent commit history makes it easier for humans to interpret the history. This facilitates faster code reviews and benefits new hires that neeed to familiarize themselfes with an existing codebase. The advantage of additional context such as ticket references is obvious.

Consider the following commit history:

commit 0d5914ca843b0129ceca84f5b0d9f6635f6dd93b
Author: Sloppy Coder <codes@sloppy.com>
Date:   Wed Mar 27 18:00:00 2019 +0100

    Fixes bug

commit 42038779e6f6eb39f491023f7ef709feec669209
Author: Sloppy Coder <codes@sloppy.com>
Date:   Wed Mar 27 18:10:04 2019 +0100

    Tweaked styling

commit 0cd47fec087cc39088bad9646fc7acf01ff7c372
Author: Sloppy Coder <codes@sloppy.com>
Date:   Wed Mar 27 18:15:08 2019 +0100

    Refactor

commit b51aff339e0aa9c91498140c310c55871edaacf5
Author: Sloppy Coder <codes@sloppy.com>
Date:   Wed Mar 27 18:21:44 2019 +0100

    Stuff

These commit messages aren't helpful because they don't contain any useful information. Compare this with the Linux' commit history. Every commit message explains the changes and motivations in great detail. An example of commit messages that follow a set of rules is Angular's commit history which uses the Conventional Commits style. Go ahead and read the Conventional Commits specification for inspiration, it is quite short.

I won't argue for a certain style, but consider the benefits of great commit messages in general, especially if the code base is large or development is expected to continue for a long time. Ideally, the chosen convention is enforced automatically in CI/CD and with git hooks.