loading...

Improving Your Commit Message with the 50/72 Rule

noelworden profile image Noel Worden Updated on ・3 min read

Last week I put up a post about setting up a custom commit message template, and I thought it would be worthwhile to write a followup post about the 50/72 Rule

The 50/72 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 is 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.

Using the 50/72 Rule, the commit logs come out looking clean and highly readable, like this, for example:

Where a log of detailed commit messages without the formatting might look something like this:

With all of that in mind, here is my default commit message template:

I'll break down the components. First is the tag and the 50 character length indicator:

If your commit workflow doesn't include ticket numbers, these tags can be super helpful. Not only is it easier to see six months from now what a particular commit did, it also keeps the repo looking clean and organized. Since its a template, I have already included the brackets, to save me some keystrokes when writing the commit.

After that is the blank line:

The note is a little redundant, but I keep it in there so I don't accidentally delete that line, and it's obvious what's happening to anyone I might have shared this file with.

Then there's the summary, with a character length indicator and some notes to myself of what tone the summary should be written in:

Lastly, the definitions of all the tags:

This is handy to have, because if I'm using this template it's usually in personal projects that I don't visit that often and I wouldn't be able to remember off-hand what they all mean.

This is a snippet of what a repo looks like when using those tags, pretty clean, eh?

Alt Text

As another example, here is the template for my current project's commit messages:

This one has the prefix of the ticket already typed out and a few more notes regarding the tone of the messages. Remember, you can have just about anything you want in your template. If you want the line to be hidden from the actual message, just begin that line with a #.

One more handy tip that I actually discovered while writing this post is if you are using VIM you can actually sit it to automatically wrap at 72 characters. It needs to be set before you start typing out the summary (where the 72 character limit is utilized):

:set textwidth=72

Below are some links with more details on the 50/72 Rule and commit messages in general. If you have any other message template workflow tips I'd love to hear about them in the comments.

https://preslav.me/2015/02/21/what-s-with-the-50-72-rule/
https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
https://vim.fandom.com/wiki/Automatic_word_wrapping
https://chris.beams.io/posts/git-commit/


This post is part of an ongoing This Week I Learned series. I welcome any critique, feedback, or suggestions in the comments.

Posted on by:

noelworden profile

Noel Worden

@noelworden

Software Engineer in Boulder, CO - Writing code and getting strategically lost in the mountains

Discussion

pic
Editor guide