Emojis and icons can be powerful way to communicate. Coding, blogging, or inputting a commit message are all forms of writing. The faster you can get your message across the better, and a picture is worth a thousand words.
About 5 months ago I started using emojis in my git commit messages. It isn't a new idea. It may be dismissed as something cute to do. However, I think it has made me a better developer.
When committing code, make your commits as small as possible. This makes it easier for the code reviewer, or anyone else, to understand the type of changes being made. It is very painful to do a code review with a thousand lines of refactoring and somewhere embedded in that is a single-line, non-refactoring critical bug fix.
Commits like that make it virtually impossible to see the behavioural changes being made to the code base. The code reviewer might catch and complain about this. But getting in the habit of putting an emoji on the commit message forces you to categorize the type of change. This forces this type of commit error to be detected before the initial local commit is made, and without need to rebase or confuse the reviewer.
There are a few other lists out there for emojis to use in commit messages. A good list is at gitmoji.dev. However, I'd recommend keeping a much smaller list. Using the emojis should make it easier to communicate, not require a decoder ring to view the history. I generally use less than a dozen. Here they are.
💡 Tip
All these emojis are easily typed in Windows. Use the Windows Key + . (period). That opens the emoji dialog. Then type the name (or partial name) of the emoji, which I'll list below. The ones you use frequently will be at the top.
💄
Refactoring only. There should be absolutely zero behaviour changes. The number of tests should not change. Whether or not they are passing doesn't change. Changing the code to add a new null check or check for zero length string in addition to null are behaviour changes and should not get this emoji.
Used just for merges of branches. It would be nice if there was a twisted leftward arrows emoji so that forward or reverse integration could be better indicated. But there isn't, so I use the same emoji for both.
Like refactoring, there shouldn't be any other changes in this commit. If there are changes, they should only be what is required to fix merge conflicts. Fixing merge conflicts shouldn't introduce any new behaviour.
⏪
Used to revert a commit.
🚴♂️
I use this one for when I am fixing up some error made just a few commits ago - i.e. in the same work cycle. It is like a “git amend” commit, but the previous commit has already been pushed. It should only be used when fixing a bug or comment that was introduced earlier on the same branch and that branch has not been merged to a shared dev or release branch. This emoji should be used when working on code that has not been release into the wild yet.
🛢
Unfortunately, there isn’t an emoji for a database (yet). The classic symbol for a database is a cylinder, and the closest I could find is the Oil Drum.
Use this whenever the code change requires a database change. Use if there is a data migration in the commit, done by the ORM code.
Used when simply upgrading dependencies/packages. Maybe you have a specific reason for upgrading a dependency, or it is just good practice to routinely keep your dependencies up to date. There may be some code fixes if there are breaking changes.
I try to keep this type of change like refactoring. There shouldn't be any behaviour changes, but your importing other peoples code so that is hard to guarantee. Avoid using this if the new version of the package causes significant changes in the behaviour of your product.
This commit emoji is for changes to the unit/automated tests only. No production code is modified in this commit. Usually this indicates an increase in test coverage.
I do try to be consistent and use the Heavy Check Mark ✔, not the White Check Mark ✅.
🔨
Hopefully your build and release process in under source control. Use this icon for changes to that area of the source code.
📝
Changes to the user documentation, help system, readme files, or code comments.
Adding (or removing) log messages made by the program, or other analytics.
⚡
A change done to speed up performance.
🔒
Adding improved security to the application.
That's it. That's the end of my list. If it doesn't fit one of these categories, then I don't add an emoji at all. I don't bother distinguishing between bug fixes 🐛, enhancements ✨, new features 🆕, or other types of changes. The differences between these types of changes can be subtle. What one user calls a bug fix another developer may call an enhancement. It is best not to waste too much time on correctly classifying all those types of changes.
Bonus Tip: Emojis can be great for log file messages too.