How can I write a useful Git commit message for a small change?
Quick answer
Describe the change in a short, specific summary, using a verb that says what the commit does. For example, “Show a warning when the search has no matches” is clearer than “Update search.” Add a brief explanation only if the reason or a non-obvious detail would help someone reviewing the history. Follow your project’s conventions when it has them; no single format suits every team.
The question, the details, the next step.
What should a commit message for a small change actually tell someone? I’ve fixed one minor behavior, and I don’t want the message to turn into a miniature changelog.
Aim to answer one practical question: “What does this commit change?” A useful summary names the affected behavior or area and describes the action. If the reason matters and is not obvious from the summary, add a short explanation below it. Leave unrelated work out; a commit message should describe this commit, not the whole task or every file you touched.
A flexible template is:
<short summary of the change>
<optional: why it was needed or a detail that helps a reviewer>
For instance:
Show a message when search has no matches
Give readers a clear next step instead of a blank results area.
Use the second line only when it adds useful context. For a self-explanatory change, the summary alone may be enough.
Can you show the difference between a vague message and a clearer one for a small change?
Suppose, as an example, a change makes the save button unavailable until a required title is entered. These summaries are hard to interpret without opening the code:
Fix form
Small update
Changes
They don’t say which behavior changed. A more informative summary could be:
Disable save until the title is entered
If the reason would otherwise be unclear, add a short explanation:
Disable save until the title is entered
Avoid saving records that are missing their required title.
The example is only a pattern, not a required wording. Pick the level of detail that helps your likely reader understand the change.
Should I use a particular tense, prefix, or length? I see different formats in different repositories.
Start by checking the project’s existing commit messages or its contribution guidance. If the team uses a prefix or a specific style, follow it so your message fits alongside the others. If there is no stated convention, choose wording that is easy to scan and consistent with your own messages.
A verb-led summary is often a straightforward choice: Add, Show, Prevent, or Rename. The important test is not whether you used one prescribed tense or prefix; it is whether the summary tells a reader what changed without unnecessary padding. Keep the subject focused. If the message needs several paragraphs to explain a small change, check that you are not trying to summarize unrelated work or repeat information already clear from the change itself.
What quick check can I use before I write it? Could you give me a copyable version?
Try this small checklist: name the behavior or area, state the change, and remove words that add no useful meaning. Then ask whether a reviewer could distinguish the commit from a generic “update” without opening it. Add a second line only when it explains a non-obvious reason or decision. Finally, check for a repository convention and adjust the wording if needed.
Copyable starting point:
<Verb> <specific behavior or area>
<Optional: why this change helps or what detail needs context>
Example:
Show a warning when the name field is empty
Help users spot the missing value before submitting.
Treat the second line as optional, not a box to fill. A clear one-line message is a good result when the change speaks for itself.
A practical checklist
Name the behavior or area affected.
Use a specific action instead of a generic label such as “update.”
Keep the summary focused on this commit.
Add context only when it explains a non-obvious reason or detail.
Check whether the repository has an established message style.
A few more useful answers
Do all commit messages need a second paragraph?
No. Add one only when it gives useful context that the summary cannot convey on its own.
Is a prefix required, such as “fix:” or “feat:”?
Only use a prefix if it fits the project’s convention or helps your team. Otherwise, a clear summary is enough.
Should the message list every file changed?
Usually not. Describe the purpose or behavior of the commit; a file-by-file inventory often adds little to a short summary.