Improving Your Commit Message with the 50/72 Rule

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.

view raw week_may25_formatted hosted with ❤ by GitHub

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:

view raw week_may25_unformatted hosted with ❤ by GitHub

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

view raw week_may25_template hosted with ❤ by GitHub

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
	#--------------------------------------------------

view raw week_may25_template_pt01 hosted with ❤ by GitHub

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
	#----------------------------------------------------------------------

view raw week_may25_template_pt02 hosted with ❤ by GitHub

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
	#---------------------------------------------------------------------

view raw week_may25_template_pt03 hosted with ❤ by GitHub

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

view raw week_may25_template_pt04 hosted with ❤ by GitHub

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?

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
	#---------------------------------------------------------------------

view raw week_may25_project_template hosted with ❤ by GitHub

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.