Understand how to write a good commit message through memes 😉

1️⃣ Why is it important to commit 🤔 ?

• To create a periodic checkpoint in your codebase.
• You can better understand how things in your code were broken.
• Let people see what really happened, having a version history is important to understand the code.
• Describe your action in terms of commit, if you don’t then you’re doomed to repeat what you did again and again in meetings, tickets, reports.

🎯 Mind that the commit messages may be reviewed with or without the code

The commit message should make sense without seeing the actual code but still should not repeat the code changes. The best way to fully grasp this is to review the log of your project, preferably commits from someone else. What makes sense? What does not? Why? Through time, you will get used to proof-read yours.

TL;DR ⏳

2️⃣ Importance of good commit message 🎯

Before I would explain the importance of a good commit message. I want to explain

Why we should a write good commit message 🤷🏻‍♂️ ?

Why is that important? Who cares about messages? You want to have good commit messages that provide you useful information about what has changed and why. Because when things really tend to go upside down, then revision history is a great resource to find out quickly where exactly things went wrong.

Any software project has at least two developers …

When you’ll be going through your own commit history after six months, then you will be definitely scratch your head, trying to remember what you were thinking exactly six months before, when you wrote that commit.

On the other hand are the “novels”. Some programmers go into much detail about what they’ve done, both in the summary and in the description. This makes it difficult to read, and understand later on, what they did exactly 😵‍💫

Being verbose is by no means a bad thing. In fact, programmers are encouraged to put lengthy details about their commits, but only in the description. The summary is what helps you and other programmers to skim through thousands of commits, so it must be both concise and insightful.

The art of writing bad commit messages probably is something that we’ve all committed to before. We’ve all both seen and written commit messages that were suboptimal — to put it very subtly.

Creating a good commit message isn’t hard at all, it only takes some effort. Though, a lot of developers tend to have the bad habit of writing poor commit messages. This is most likely due to not recognising the importance of a good commit message.

Example of the poor commit message 🤮

How to write a git commit message properly is a topic that’s been broached many times. Of course, any seasoned developer who’s gone through git logs in a project they’ve just dropped into can tell you that developers need constant reminders of the git commit message guidelines.

3️⃣ 10 Commit Rules 🎯

I want to take a moment to elaborate on what makes a well-formed commit message. You just need to follow below 10 rules which will make your commit message a bit cleaner and also looks nicer, something like this :

The 10 commonly accepted rules on how to write a git commit message are:

1. A commit message is comprised of a subject ( i.e summary), body, and footer, with both the body and footer being optional.
2. Limit the subject line to 50 characters.

• The subject is a single line that best sums up the changes made in the commit.
• The act of summarising your commit is a good practice inherently in any version control system. It helps others (or a later you) find relevant commits more quickly.

3. Capitalise the first letter of the subject line.

4. Don’t put a period ( . ) at the end of the subject line.

5. Put a blank line between the subject line and the body & also between body and footer.

• The blank line separating the summary from the body is critical (unless you omit the body entirely) the footer should also be separated from the body by an empty line.

6. Wrap the commit body at 72 characters.

• The body text is used to provide more details regarding the changes made in the commit.

7. Write the commit body in bullets (OPTIONAL).

• Commit body looks clean when written in terms of bullets.

8. Use imperative mood

• Example: Say Add instead of Added
• Say Fix instead of Fixed, Fixes → Use present tense imperative for the subject line and present tense for body text
• The present imperative should be used for the subject line of commit messages. This is what has been standardized by git itself.

Even, GitHub uses Create and Update keyword instead of using “Created” and “Updated”

9. Describe what and why, but not how.

• Maybe Mention Which component is changed.
• Just keep your mind on the purpose, not the implementation.
• Most of the modern bug-tracking and project management systems provide integration with the source control repository, but even if they don’t, you can still drop task/ticket numbers in the commit message – something like this. Of course – don’t rely on this being the only description of your message.

10. Footer contains issue no. and ticket if needed (OPTIONAL).

• The footer text is found immediately below the body and is a place to reference issues related to the commit changes. Example Mention Issue no. in GitHub and If you are using JIRA to manage your project

git log does not handle wrapping, so it is hard to read if lines are too long.

If the description of the commit is not constrained to 72 characters 😈
then the commit body will span the full width of the command line making the commit message more difficult to read.

Here’s how a commit message looks like in git when you are not limiting the commit body length.

Wrapping text at 72 characters prevents text from spanning the full width of your command line window and allows for better readability of commits.

Note: Github will automatically wrap the commit body if it extends beyond 72 characters 😳

4️⃣ What is the 50–72 Commit rule?

The 50/72 the rule is a set of standards that are pretty well agreed upon in the industry to standardize the format of commit messages. 50 is the maximum number of characters of the commit title, and 72 is the maximum character length of the commit body. These aren't arbitrary numbers that someone just pulled out of a hat.

An analysis of the commit messages in the Linux kernel revealed that

• 50 characters are the most common length of a commit title.
• The number 72 comes from the fact that 80 characters

is the widely accepted industry standard for readable character length of one line, git automatically adds a padding of 4 characters to the left of the commit message body, and to keep everything centered and looking nice, 4 characters should be padded to the right. Also, if an empty line separates the commit title from the body, git will automatically separate the two appropriately.

5️⃣ Use VS Code to write your commit message 🔥

You can use any editor as you prefer eg. vim, nano, git bash (default).

If you use VSCode as your default git editor, then whenever you execute git commit, VSCode will open up for you to type in your commit message. The commit message is saved once you’ve closed the VSCode tab (can be done with CTRL + W or ⌘ + W). What is especially nice about this is that you can configure VSCode to set vertical rulers that can act as guides for the line length limits you wish to follow.

Watch below video on 2x ⚡️

The green line is for the commit title which is less than 50 Characters.
The orange line is for the commit body which is less than 72 Characters

3 Steps to add vertical ruler in VSCode 🚀

1. Add VSCode to that environment variable: Follow the instruction from here
2. You can set VSCode as your default git editor by executing the following command in your shell:

3. Press CMD + SHIFT + P In mac or CTRL + Shift + P in Windows.
Then type Open user setting JSON. Add below snippet in settings.json

Hurray, you’ve successfully set ruler in your VSCode 🎉

BONUS : if you write good messages, you will be able to generate a changelog directly from your commit messages 🤯

Also, you can prefix your commit title with emoji 🤩

An emoji guide for your commit messages: https://gitmoji.dev/

Acknowledgment of the few reference which I’ve used for creating this blog post, the intention was just to share the knowledge with other folks.

Reference :

1. Tim Pope, “A Note About Git Commit Messages”,19 Apr 2008 — https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
2. David J., StackOverFlow, “Git Commit Messages: 50/72 Formatting”: https://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting
3. Robert Cooper, “How to write a commit message that will make your mom proud”, June 17, 2021: https://robertcooper.me/post/git-commit-messages
4. Preslav Rachev, “What’s with the 50/72 rule?”, Fab 21, 2015: https://preslav.me/2015/02/21/what-s-with-the-50-72-rule/
5. Noel Worden, “Improving Your Commit Message with the 50/72 Rule”, Sept 9, 2021: https://dev.to/noelworden/improving-your-commit-message-with-the-50-72-rule-3g79
6. TheServerSide, “How to write a Git commit message properly with examples”, May 8, 2021: https://www.theserverside.com/video/Follow-these-git-commit-message-guidelines
7. Daan, “The Importance of Good Commit Messages”, May 13, 2020: https://levelup.gitconnected.com/the-importance-of-good-commit-messages-9331251e5e33
8. Petyo, “The importance of commit messages”, Nov 11, 2008: https://wildbit.com/blog/2008/11/11/the-importance-of-commit-messages

Great resources shared by Derek Murawsky 🤗

1. The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of.
   source: https://www.conventionalcommits.org/en/v1.0.0/
2. Chris beams, “How to Write a Git Commit Message”, Aug 31, 2014: https://chris.beams.io/posts/git-commit/

Social 🌐:

GitHub: https://github.com/hritik5102
Linkedin: https://www.linkedin.com/in/hritik-jaiswal-22a136166/
Twitter: https://twitter.com/imhritik_dj
Linktree: https://linktr.ee/hritikdj

Support me

https://www.buymeacoffee.com/hritikdj