loading...

Improving Your Commit Message with the 50/72 Rule

noelworden profile image Noel Worden ・6 min read

This Week I Learned (16 Part Series)

1) Beginning of a Blog Series 2) Accessing localhost within a Docker Image 3 ... 14 3) Identifying and Removing Hidden Characters 4) Getting Granular with Git Diff 5) Tweaking Logger Outputs on the Fly 6) Keeping Your Hands on the Keyboard: A Few Bash and Git Shortcuts 7) Breaking Down Elixir's `with` Expression 8) How To Write A Custom Elixir Schema Validation 9) The Handful of Commands I Use When Interactive Rebasing with Vim 10) Got 5 Minutes to Spare? Why Not Set up a Custom Commit Message Template? 11) Improving Your Commit Message with the 50/72 Rule 12) Synchronously Looping Over Two Collections in Elixir 13) How to Utilize Enum.any?, with a Refactoring Twist! 14) A Rabbit Hole of Decimal Formatting 15) More Custom Validation Work: Manipulating a Keyword List To and From a Map 16) Stepped Away for a Long Weekend

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:

commit e54d3c604a9a852822c0a8866aaa80106064952b
Author: Noel Worden
Date:   Fri May 22 14:40:23 2020 -0600

    FAM-229: Refactor validation logic

    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
    tempor incididunt ut labore et dolore magna aliqua. Fames ac turpis egestas
    maecenas pharetra convallis posuere morbi.

commit 10b0711f78a0485ca7eee216aefbc114c1ka62601
Author: Noel Worden
Date:   Thu Apr 30 16:07:15 2020 -0600

    Fix: Tweak error-logging logic in Pipeline

    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
    tempor incididunt ut labore et dolore magna aliqua. Enim nunc faucibus a
    pellentesque sit amet porttitor eget dolor.

commit 728b61ec0939c9be7713f4adp9ube50e3be7440a
Author: Noel Worden
Date:   Tue Apr 28 08:36:05 2020 -0600

    FAM-229: Validate profit_after_split

    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
    tempor incididunt ut labore et dolore magna aliqua. Vel turpis nunc eget
    lorem dolor sed viverra ipsum. Commodo sed egestas egestas fringilla
    phasellus.

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

commit e54d3c604a9a852822c0a8866aaa80106064952b
Author: Noel Worden
Date:   Fri May 22 14:40:23 2020 -0600

    FAM-229: Refactor validation logic

    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.Fames ac turpis egestas maecenas pharetra convallis posuere morbi.

commit 10b0711f78a0485ca7eee216aefbc114c1ka62601
Author: Noel Worden
Date:   Thu Apr 30 16:07:15 2020 -0600

    Fix: Tweak error-logging logic in Pipeline

    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Enim nunc faucibus a pellentesque sit amet porttitor eget dolor.

commit 728b61ec0939c9be7713f4adp9ube50e3be7440a
Author: Noel Worden
Date:   Tue Apr 28 08:36:05 2020 -0600

    FAM-229: Validate profit_after_split

    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Vel turpis nunc eget lorem dolor sed viverra ipsum. Commodo sed egestas egestas fringilla phasellus.

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

[]
#--------------------------------------------------
# [ FEAT BUG CHG REFAC PERF DATA TOOL COPY DOC SPEC WIP ]
# Do not exceed above line in commit txt length
#--------------------------------------------------
# This is the empty space to separate the title from the body

#---------------------------------------------------------------------

#---------------------------------------------------------------------
# Description of why, not how.
# Link to issue, if needed.
# Wrap summary text at the end of the above line, do not exceed line
# length
#---------------------------------------------------------------------
#FEAT - feature, new stuff to the site
#BUG - any bug fix you put in place
#CHG - change that is NOT a refactor or a COPY change
#REFAC - refactors existing code but does not change functionality
#PERF -  effects the performance of the application, ie: adding sidekiq or where-exists
#DATA -  only effects the data directly, ie: add to or remove from the seed file
#TOOL - does not directly effect site users, developer or testing space, ex: pry or rubocop
#COPY - only text changes
#DOC - changes to documentation
#SPEC - any test or spec changes
#WIP - work in progress. USE SPARINGLY

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

[]
#--------------------------------------------------
# [ FEAT BUG CHG REFAC PERF DATA TOOL COPY DOC SPEC WIP ]
# Do not exceed above line in commit txt length
#--------------------------------------------------

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:

# This is the empty space to separate the title from the body

#----------------------------------------------------------------------

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:


#---------------------------------------------------------------------
# Description of why, not how.
# Link to issue, if needed.
# Wrap summary text at the end of the above line, do not exceed line
# length
#---------------------------------------------------------------------

Lastly, the definitions of all the tags:

#FEAT - feature, new stuff to the site
#BUG - any bug fix you put in place
#CHG - change that is NOT a refactor or a COPY change
#REFAC - refactors existing code but does not change functionality
#PERF -  effects the performance of the application, ie: adding sidekiq or where-exists
#DATA -  only effects the data directly, ie: add to or remove from the seed file
#TOOL - does not directly effect site users, developer or testing space, ex: pry or rubocop
#COPY - only text changes
#DOC - changes to documentation
#SPEC - any test or spec changes
#WIP - work in progress. USE SPARINGLY

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:

FAM-:
#------------------------------------------------
# Add ticket number
# Answer this question: If applied, this commit will...
# Do not exceed above line in commit txt length
#------------------------------------------------
#This is the empty space to separate the title from the body

#---------------------------------------------------------------------

#---------------------------------------------------------------------

# Description of what and why, not how.
# Wrap summary text at the end of the above line, do not exceed line
# length

# Additional commit notes:
# https://chris.beams.io/posts/git-commit/
# https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L124-L141
#---------------------------------------------------------------------

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.

This Week I Learned (16 Part Series)

1) Beginning of a Blog Series 2) Accessing localhost within a Docker Image 3 ... 14 3) Identifying and Removing Hidden Characters 4) Getting Granular with Git Diff 5) Tweaking Logger Outputs on the Fly 6) Keeping Your Hands on the Keyboard: A Few Bash and Git Shortcuts 7) Breaking Down Elixir's `with` Expression 8) How To Write A Custom Elixir Schema Validation 9) The Handful of Commands I Use When Interactive Rebasing with Vim 10) Got 5 Minutes to Spare? Why Not Set up a Custom Commit Message Template? 11) Improving Your Commit Message with the 50/72 Rule 12) Synchronously Looping Over Two Collections in Elixir 13) How to Utilize Enum.any?, with a Refactoring Twist! 14) A Rabbit Hole of Decimal Formatting 15) More Custom Validation Work: Manipulating a Keyword List To and From a Map 16) Stepped Away for a Long Weekend

Posted on Jun 1 by:

noelworden profile

Noel Worden

@noelworden

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

Discussion

markdown guide