Git commit logs need to provide information, but if they are too wordy they can hide the changes/issues covered and make a mess of reports generated on the command line.
I’ve been trying to steadily improve my use of Git since I began using it a few years ago and recently I’ve been focussing on making my commit messages better.
This post is just a few short tips to make the messages better, and hopefully more useful for your colleagues as well as that most critical of people, future you
These tips have been gathered from various posts on the topic and are mainly here for my own memory and for something to point to when discussing this in my Git Crash Course
Write as if you are telling someone what to do! ‘Fix’, ‘Replace’, ‘Change’ not ‘Fixed’, ‘Replaced’, ‘Changed’
Write a summary line Start the message with a single summary line. Don’t try to explain everything just enough to cover the main points. Keep it short (below 60 characters seems about right)
Leave a blank line After the summary leave a blank line to separate it from the next portion of text
Write a more verbose explanation Add a longer description of what was done, why it was done if it needs explaining, and add any ticket or bug request numbers to help link to other pertinent information Force wrap this message at the 72 character mark. Many people use Git from the command line and this limit will allow them to read the logs without lots of tiresome side-scolling
Think like you are writing an email, with a subject and body separated by a blank line.
Example:
Change the initialize method to call user state
Add a call to the User::state method in the class initialise method so that the users state is
available throughout the instance lifetime