39 lines
1.5 KiB
Markdown
39 lines
1.5 KiB
Markdown
|
---
|
||
|
|
title: Writing good commit messages
|
||
|
|
date: 2025-04-04
|
||
|
|
permalink: daily/2025/04/04/good
|
||
|
|
tags:
|
||
|
|
- software-development
|
||
|
|
- git
|
||
|
|
cta: ~
|
||
|
|
snippet: |
|
||
|
|
What is a good commit message? How is it structured and what information should it contain?
|
||
|
|
---
|
||
|
|
|
||
|
|
There are many good resources and interesting articles online about how to write good messages when committing changes to a Git repository.
|
||
|
|
|
||
|
|
The post I often refer to is [How to Write a Git Commit Message][0] by Chris Beams.
|
||
|
|
|
||
|
|
In his post, he explains why good commit messages matter and gives these seven rules:
|
||
|
|
|
||
|
|
> - Separate the subject from body with a blank line.
|
||
|
|
> - Limit the subject line to 50 characters.
|
||
|
|
> - Capitalize the subject line.
|
||
|
|
> - Do not end the subject line with a period.
|
||
|
|
> - Use the imperative mood in the subject line.
|
||
|
|
> - Wrap the body at 72 characters.
|
||
|
|
> - Use the body to explain what and why vs. how.
|
||
|
|
|
||
|
|
I'd recommend reading the article to get the full context.
|
||
|
|
|
||
|
|
Rules two and six suggest lengths for the subject line and body which is another reason [why I rarely use `-m`][1] when committing changes.
|
||
|
|
|
||
|
|
Whilst you can create multi-line commit messages on the command line, by opening it in my preferred editor (Neovim for me), I can see where the lines should end and be warned if I exceed them.
|
||
|
|
|
||
|
|
I can even include Chris' rules in my commit message template so I see them whenever I'm about to commit something.
|
||
|
|
|
||
|
|
This additional feedback helps me create my commit messages how I intend.
|
||
|
|
|
||
|
|
[0]: https://cbea.ms/git-commit
|
||
|
|
[1]: {{site.url}}/daily/2025/04/02/commit
|