Hunter’s Committing Conventions

The 50/72 Rule

The 50/72 rule is fairly simple. A commit should be formatted as follows:

This is my commit title; it can be up to 50 chars

This is my commit body. I type in complete sentences and bulleted 
lists, but it should always wrap at 72 chars.

Why these numbers? 50 characters leaves enough space in the rebase editor, the logs, and many branch completion hints so that the full commit message can fit in the space given. 70 is a reasonable width to assume for terminals of a usable size, so that if I’m inspecting a commit, I can see the full body without needing to scroll. Following these assumptions means that my commits will work well for anyone’s environment, whether they’re in a limited-space terminal or a full commit browser.

I try to follow this as closely as I can, and use tools to help me do so. One such tool is the vim editor for commits, and another is the VSCode commit editor. Vim changes the text color when I go over the 50 limit and wraps my body text for me; VSCode warns me when I go over either of the limits.

Commit Title is a Title, not a Sentence

I used to be of the school of thought that a commit summary should be a complete sentence describing my changes as a whole, but eventually I’ve come to realize that it’s really a title for the changes that I’m making, and that I can use the body to describe the changes I’m making. There were also times that I’d fight for a single character of space to try and fid in a stubborn period. If I think of commits summaries as titles rather than sentences, I don’t run into this problem anymore, and I have an entire extra character to play with.

The Imperative Mood

This one is fairly standard and not very divisive; commits should be written in the imperative mood, or in other words, as if they were a command rather than a statement of what I did. For example “add css files to the frontend” over “added css files to the frontend”. This makes a small difference, but using this mood I can read each commit in a sentence like “this commit will _________”

Another reason to use this is because git is already using this mood; when you revert a commit, the commit message is “revert ‘________'”, and likewise when you merge a branch.

Conventional Commits, Gitmoji, or Both

Conventional Commits and Gitmoji are two of my favorite commit style guides. Conventional Commits is really cool, because there are tools that I can use that generate easy changelogs and semver versions from my commit history if I stick to following the spec laid out in Conventional Commits.

Gitmoji is interesting, and can be fairly divisive because programmers either do or do not like emojis, and finding a good monospace font that supports them as well can be difficult, espeically once powerline fonts and other such things are thrown into the mix. However, I find that the emojis are a super quick way for me to look at a log and see what each commit is doing just based on the colors and the symbols of the emoji. It’s similar to how I organize discord channels; the emojis make the channels much easier to grok and find quickly.

I’ve used both together, but I’m not sure I’d recommend it; most of them take up a good number of characters for the beginning of a commit, and so generally I go with one over the other. If I could get some good gitmoji tooling, I bet that would be the one that I’d use all the time.

Code Review Belongs in Code Review, not Commits (Using Fixup Commits)

Here’s another one that not everyone follows, much to my behest. At work I’ll be going through the commit log, and while most of the commit messages in a git blame will look something like “add feature X”, sometimes I’ll encounter a commit that instead reads something like “address code review comments”. In order to get useful information from that git blame, I often have to hope that the ticket number was included in the commit (which it rarely is in commits of those sort), or try to look for that commit’s parent, which is not my favorite either.

I offer a better way: fixup commits.

I believe that all code review commits should be squashed into their original commits, or if they don’t fit into the original commits, a set of new commits should be broken off from the originals. What fixup commits allow you to do is stage and commit changes that should end up inside of a previous commit, and then help you get them there while rebasing.

The way you do this is you choose a commit for your changes to be merged with, then commit like this:

git commit --fixup=[id of commit you want these changes to land]

Once you’re done making code review changes, you can run this command:

git rebase --autosquash HEAD~5

Replacing HEAD~5 with however many commits you want to go back, including the number of fixup commits you’ve used. This will put you into a rebase editor with some commits already in place above other commits with the fixup prefix, which does the same thing as a squash command, merging the commits together, but the fixup command also disregards the commit message instead of combining it.

These are really slick for using git as a source of truth, and for keeping commit history clean. If everyone did this, I’d be able to see when and why each piece of code was placed where it was. That seems like a small thing, but it can go a long way when trying to figure out why a file was written the way it