Code reviews and assessments are two of the most useful parts of the Learn Verified program. A key thing that I learned during my Rails Assessment a few weeks ago is that potential future employers are going to be critically looking at your GitHub commit history. Well I knew that people would check out my GitHub of course, but it helped to know what others are looking for.

Now there are quite a few different schools of thought about how to write the best (aka most useful to other people checking out your code and your future self as well) commit message, but I’ll try to summarize what I’ve learned via assessment conversations and comparing notes.

One thing that I heard that surprised me is that employers will look at your commits and actually compare your changes with the description. Do they match? Or are there other things in there that you forgot to mention? Are the commits regular? I will admit that in the past I was not great about this. In the past I was committing willy-nilly. At certain points I would be like “Oh I haven’t committed in a while, better take care of that”, and then I would try to remember what I’d done since my last commit. Bad idea!

DOs

• Commit early and often. Perhaps every 5 – 10 minutes. Something is worth committing when you’ve been really typing for a bit.
• Consider making your commits feature-based. So for example:

• Set up User authentication with Devise

• Move jquery and bootstrap from script tags in layout erb to gems in asset pipeline; fix the issue of nav button dropdowns not working after creating a new attraction by adding document.ready(toggle) to js

• I haven’t tried this yet, but have a subject line and a body, leaving a line in between for readability.  Capitalize your subject line, which is really a short summary of the change (50 characters or less). Use the body for explanation. Blank lines between paragraphs. Thoughtbot suggests ditching the -m flag altogether, to get yourself in the right state of mind.
• Probably most important: Explain why the change was made, how it addresses the issue, any design decisions, and any foreseeable side effects the change will have.
• I suppose this is a syntax and style thing, but it seems like most people prefer the imperative tense as it implies a command and matches Git’s tense. So, “Fix” or “Change” instead of “Fixed” or “Changed” for example.
• Wrap your commit messages to 72 columns to prevent overflow. This is another thing I haven’t tried yet.
• Say you thought you had fixed an issue during a certain commit. Say you realize that no, this time you’re really fixing that feature. Instead of committing “Fixed Feature X for real this time”, you can go back and amend your previous commit. Check out git commit –amend.

Phew! That was a lot, but if you think about it, it’s mostly common sense.