Your team should pick a commit style

As developers, we all know and use Git. The ability to track changes and collerate with anyone is a cornerstone of modern development. If you have worked in a team on a project for the span of multiple years you you might have struggled to understand why code is even there. When looking at the Git commit you see:

WIP - Old team member - 8 years ago

Why a commit style matters:

Providing Context: A well written commit is a concise summary for the changes in that commit. If you commit small and commit often you can summarize your changes in a few words:

• Add back button to cart page
• Improve product search performance
• Seperate cart logic into seperate service

Developer intent: Looking back at old commits, especially from years ago, can be like deciphering a cryptic code. Without proper context, it's difficult to understand the rationale behind those changes and how they fit into the project's history.

• Refactor recommendation grid into multiple components
• Conditionally render button according to order status
• Fix tooltip z-index for usage in dialogs

Consistency just feels nice and indicates discipline

It is satisfying looking at a codebase where a commit style guide is strictly followed. It indicates developer discipline too. I’ve worked on teams where applying a commit convention was not even negotiable. To me, a younger and more junior developer at the time this felt frustrating.

If you don’t care about your commit messages, comments and documentation this mindset wil inevitably carry trough to your code in some capacity.

If you squash and merge it’s a different story, as long as your master branch is clean.

Pitfalls

Commit messages should not be something that holds you back, Personally, I’m skeptical about precommit hooks which validate your commits or about running tools for checking this in pull requests.

Iteration velocity solves all known software issues. ~ Malte Ubl

Some examples

One of the most popular conventions is Conventional Commits, a lightweight specification for writing commit messages. It is simple to understand and easy to be consistent in. We use it at my company and I’m very happy with it.

feat(cart): add back button to cart page

fix(search): improve product search performance

refactor(cart): seperate cart logic into seperate service

You can also use emojis to indicate the type of commit, this is a bit more playful but can be fun to use.

A good commit should follow the following structure:

<type>(<scope>): <subject>
fix: (cart): add back button to cart page (50 characters or less)

Then a longer description if needed, if your changes are self explanatory you can skip this part.
Most renders will only show the first line of the commit message.

Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug."
This convention matches up with commit messages generated by commands like git merge and git revert.
Git only knows about the change when you commit it, so it makes sense to use the imperative mood.

- Bullet points are also a good way to structure your commit message,
  especially if you have multiple changes in one commit.
You can also add a reference to a ticket or issue number if you have one.

See: https://www.conventionalcommits.org/en/v1.0.0/

Conclusion

A commit style is a small thing that can have a big impact in the longrun. It can provide context, developer intent and consistency. It can also be a fun way to express yourself instead of just "wip". If you are not using a commit style guide I would recommend you to start using one. It can be as simple as a few rules or as complex as a full blown specification with tooling around it. It’s up to you and your team to decide what works best for you.

$ git commit -m "It's not that hard, you just need to git good"