How long should a git commit message be?

The subject line should be 50 characters or less. If you need to explain more, add a blank line after the subject and write a detailed body, wrapping lines at 72 characters. The subject is for the "what", the body is for the "why".

What is Conventional Commits?

Conventional Commits is a specification for structuring commit messages with a type prefix like feat:, fix:, docs:, refactor:, test:, or chore:. It makes the history more readable and enables automated tools like changelog generation and semantic versioning.

Should I use past tense or imperative mood in commit messages?

Use imperative mood (e.g., "Add feature" not "Added feature"). Think of it as completing the sentence "If applied, this commit will..." — "If applied, this commit will add feature". This is the convention used by Git itself.

When should I write a commit body?

Write a body when the "why" behind a change is not obvious from the code. Bug fixes, architectural decisions, and trade-offs are great candidates. Simple changes like fixing a typo or updating a dependency version usually don't need a body.

Can I change a commit message after committing?

Yes, use "git commit --amend" to change the last commit message. For older commits, you'll need an interactive rebase with "git rebase -i". Be careful: amending changes the commit hash, so avoid it on shared branches.

Git Commit Messages: best practices that matter

Your commit messages are the documentation of your project's history. Learn the rules, formats, and habits that make them actually useful.

Practice Git commits Git glossary

gitquest — enquête

Anatomy of a good commit message

Subject line (required)

A short summary of the change, 50 characters or less. Written in imperative mood ("Add feature" not "Added feature"). No period at the end.

feat: add email verification on signup

Blank line (separator)

Always separate the subject from the body with a blank line. Git uses this to distinguish the summary from the description.

Body (optional)

Explain why the change was made, not what (the diff shows the what). Wrap at 72 characters. Reference issues or tickets when relevant.

Users were able to sign up with invalid emails,

leading to bounced notifications. This adds a

verification step before account activation.

Closes #187

The golden rules

7 rules for great commit messages

These conventions are widely adopted in the industry. Follow them and your teammates will thank you.

Keep subject under 50 chars

Forces you to be concise. GitHub truncates after 72 characters anyway.

Capitalize the subject line

"Fix bug" not "fix bug". Start with an uppercase letter for consistency.

No period at the end

The subject line is a title, not a sentence. Every character counts in 50 chars.

Use imperative mood

"Add feature" not "Added feature". Matches Git's own conventions (e.g., "Merge branch").

Blank line before the body

Required for git log, shortlog, and many tools to work correctly.

Wrap body at 72 characters

Git doesn't wrap text automatically. Keep lines readable in terminals and log views.

Explain why, not what

The diff shows what changed. The message should explain the motivation behind the change.

Conventional Commits format

A popular convention that prefixes each message with a type. Enables automated changelog generation and semantic versioning.

feat:

A new feature for the user

feat: add dark mode toggle

fix:

A bug fix

fix: resolve login timeout issue

docs:

Documentation changes only

docs: update contributing guide

refactor:

Code change that neither fixes a bug nor adds a feature

refactor: simplify auth middleware

test:

Adding or updating tests

test: add e2e tests for checkout

chore:

Maintenance tasks (deps, CI, tooling)

chore: upgrade eslint to v9

Good vs bad: spot the difference

Compare a clean git log with a messy one. Which project would you rather join?

Good messages

gitquest — good log

# A clean git log with good commit messages

$git log --oneline -5

a3f7b21 feat: add email verification on signup

e5c9d14 fix: prevent double form submission

b8a2e67 docs: update API authentication guide

1c4f9a3 refactor: extract validation logic into helper

d7e6b52 test: add unit tests for payment module

Clear, scannable, and informative history

Bad messages

gitquest — bad log

# A messy git log with bad commit messages

$git log --oneline -5

f2d8a91 fix stuff

c7b3e45 WIP

9a1d6f3 update

4e8c2b7 changes

6f5a9d1 asdfgh

Impossible to understand what happened

Before and after: rewriting bad messages

Bad

fix stuff

What was fixed? Where? Why?

Good

fix: prevent crash when user profile is null

Clear type, scope, and what was fixed.

Bad

updated the code for the new design system colors and also changed some button styles and fixed a few things in the header

Way too long, mixing multiple changes, no structure.

Good

refactor: migrate button styles to design system tokens

One change per commit. Split the rest into separate commits.

Bad

WIP

Not a commit message. Use branches or stash for work in progress.

Good

feat: add initial search bar component (no results yet)

Honest about the state, but still descriptive.

Writing commits: editor vs inline

Use git commit for detailed messages or -m for quick ones.

With editor (detailed)

gitquest — editor

# Write a detailed message using your editor

$git commit

# Opens your default editor with:

feat: add password strength indicator

Display a visual strength bar below the password field.

Uses zxcvbn library for entropy calculation.

Closes #234

[main a3f7b21] feat: add password strength indicator

With -m flag (quick)

gitquest — inline

# Quick commit with -m flag (short messages only)

$git commit -m "fix: prevent crash on empty input"

[main e5c9d14] fix: prevent crash on empty input

1 file changed, 3 insertions(+), 1 deletion(-)

# Add both subject and body with two -m flags

$git commit -m "refactor: extract auth middleware" -m "Move token validation and role checking into a reusable middleware to reduce duplication across route handlers."

[main b8a2e67] refactor: extract auth middleware

Part of the Git Basics guide

GitQuest is created by Anaïs (nouvelle fenêtre), web developer and head of education, specializing in tech training and digital accessibility.

Questions about commit messages

Practice writing great commits in a safe terminal

GitQuest investigations put you in real-world scenarios where clear commit messages make the difference.

Start the investigations