A while back, I wrote an article about five best practices for using Git (or any SCM for that matter). One of the core tenets, I believe, is a well-written commit message. Having a well-written commit message is like being able to talk to your future self or even better, others.
🌈 changed project to use Material Design
The Blame Game
How this comes into play is one of my favorite Git commands, git blame. Git blame allows you to look at a file, line-by-line, and see the latest commit that is related to the line you’re looking at. This is useful for finger-pointing ☝️, but more importantly, it’s a way to get a comment for every line of code. There are several tools and plugins out there that allow for annotations that show the commit ID, committer, and comment for each line. I won’t go into any of them, but they are typically supported in your every day IDEs.
Code comments can easily be lengthy or messy and, at times, you can easily lose the code you’re trying to read if the file you’re looking at is overly commented. I’m all for good, documented code, but script please!
Git commit messages can be a very valuable tool if you’re looking at foreign code and you’re trying to guess what the programmer before you was thinking, even if that programmer was you.
The Box Principle
I love to describe a Git commit like a box 📦.
Imagine a box. You can put stuff into the box. You can take stuff out of the box. This box is the staging area of Git. You can craft commits here. Committing is like sealing that box and sticking a label on it. The contents of that box are your changes. So, why not have the label mean something? You wouldn’t label a moving box with kitchen items “stuff.”
Jeremy Mack wrote a great article about using Semantic Commit Messages and I’d like to expand on that. His point is coming up with “categories” for commit messages and keeping the message short. Here are some basic rules to follow:
- A commit can only have one category. If a commit has more than one category, it should be split into separate commits.
- A commit message should be short, but descriptive. If it feels too wordy, split the commit until smaller hunks and give those smaller commits more meaning.
If you’re following some of my tenets of committing early, often, and atomic, semantic commits should be a breeze ⛅️.
Ok, but what about Emojis 🤔
My fifth tenet talked about using a remote repository and pushing to it. Chances are, when you read “remote repository” it’s likely you’re either thinking GitHub or Bitbucket.
Most people use emojis to convey an emotion or idea. Whether you’re angry about something 😠 or feeling a little goofy 😜, there’s an emoji for just about everything. I was surprised how many services support emojis in text.
Mack talks about different types of commits such as docs for updating documentation and fix for, well… fixing code. I’d like to propose something radical and exciting: semantic emojis.
Don’t get me wrong, if you’re not into emojis, I highly recommend Jack’s style of commit messages.
chore: add Oyster build script
docs: explain hat wobble
feat: add beta sequence
fix: remove broken confirmation message
refactor: share logic between 4d3d3d3 and flarhgunnstow
style: convert tabs to spaces
test: ensure Tayne retains clothing
Since most of us are using a hosted-service to look at commits, review pull-requests, and generally do quite a lot of heavy-lifting outside of our terminals, let’s make it interesting.
Commit with feeling
It will take a little getting used to at first, but the result is something beautiful. The concept is simple, instead of using words to convey commit types, we use emojis instead.
Disclaimer: this is my opinionated view on which emojis to use for each type of commit. This is not all-encompassing and feel free to modify how you see fit.
Let’s get right to it.
To use emojis in your commits, you have to type them out using colons (:). You can use this site as a dictionary. 😃 creates 😃
Most of the time, I’m either adding features (⭐️ )or fixing bugs (🛠 ) so a commit of that type would be something like:
⭐️ add a new dropdown to allow better searches
When I’m fixing code (🛠), I could use a commit like this:
🛠 fix backend to optimize dropdown loading
As you’re developing your softwares, especially open-source software, it’s important to maintain good documentation (📝) .
Chores (😒) are never fun, but they are what they are and have to be done. The unamused emoji is good for that.
😒 add packages that were missing
Sometimes you aren’t writing new code ⭐️ or fixing bugs 🛠, but cleaning up code either to make it work better or just be easier to read. Most of us call this refactoring ♻️. Yes, I know that’s the recycling symbol, but it’s a good way to view it. 😜
Good code is well-written and easy to read, great code is backed by automated tests 🔍
Finally, sometimes you’re changing colors or giving your fonts a facelift. It’s the kind of work that makes you go “Ahh” and let out a sigh of relief because you made your code and your app beautiful 🌈.
Let’s Review
Writing good commits not only helps you in the future, but can save hours of pouring over code finding what’s wrong.
⭐️ for commits related to adding new features.
🛠 for commits related to fixing broken code.
😒 for commits that are just chores.
📝 for commits related to adding and maintaining documentation.
♻️ for commits related to refactoring code and making it work better.
🔍 for commits related to writing or fixing tests.
🌈 for commits related to making your code or your app beautiful with style changes.
Your git log may look a little weird, but that’s ok! As long as your commit messages mean something, they will look prettier for it!
There are tons of emojis out there and as I stated above, this is my own opinionated list. Feel free to swap out my choices or add your own. I’d love to hear which emojis you’ve chosen!
Other Resources:
Edit: Changed examples to imperative sense.
Top comments (0)