I recently read a short pro tip by Simon Owen on coderwall about commit messages (see here). It turns out it’s not just me that gets frustrated with incorrectly formatted git commit messages, especially if you pull request or are working on one of my repositories.
Please read this before you do another git commit. There is a right way and a wrong way to write your git commit messages.
The right way
Follow these simple guideline(s):
- Stick to a maximum of 50 characters for the summary to briefly describe the commit
- Capitalise the first letter
- Write in the imperative (e.g. “Fix bug” or “Add file” not “Fixed bug” or “Added file”)
- Don’t end with a full stop
- Reference issue numbers with a #
- If used, wrap the descriptive body to 72 chars with a blank line above it (I rarely go beyond a summary in practice)
- Prefix with “area: “ where the area is an identifier for the area of the code the commit relates to (personally I don’t do this but it can be useful in some circumstances)
Following the guidelines will make it easier for you to review and identify commits (especially with git log, which has no raw wrapping) and it also makes it easier for your fellow developers to work with you.
If you take a look at auto generated git messages, you’ll see they conform to the above guidelines (e.g. git merge or git revert).
Automated user git messages
Bad bad bad. You’re not adding any value by doing this. You can always alias if you don’t want to type git commit -m.