← Back to Git Course | Chapter 8: Best Practices | Lesson 2 of 6

Git Commit Message Best Practices

A good commit message is like a clear label on a moving box: a short title on top and, if needed, a few lines telling what is inside and why.

In this page:

  1. The Structure of a Good Commit Message
  2. Using Semantic Prefixes
  3. Keeping Messages Imperative
  4. Referencing Issues and Pull Requests
  5. Amending a Commit Message
Syntax
bash 
git commit -m "Summary line in imperative mood" -m "Longer explanation of what and why."
git commit -m "type: short description"

The Structure of a Good Commit Message

The convention is a short summary line (ideally under ~50 characters), a blank line, then a body paragraph explaining the reasoning behind the change. The summary alone should make sense in a one-line git log --oneline list; the body is where you explain *why*, since the diff itself already shows *what*.

Example: The Structure of a Good Commit Message

bash 
git commit -m "Fix null pointer in checkout flow" -m "The cart total crashed when the discount field was empty because it was never defaulted to zero."

Using Semantic Prefixes

Prefixes like feat:, fix:, docs:, and style: (part of the Conventional Commits convention) let you tell at a glance what kind of change a commit is without reading its full message, and tools like changelog generators can parse them automatically to build release notes.

Example: Using Semantic Prefixes

bash 
git commit -m "feat: add dark mode toggle"
git commit -m "fix: correct off-by-one error in pagination"

Keeping Messages Imperative

Writing "Add login validation" instead of "Added login validation" matches the phrasing Git's own auto-generated messages use (e.g. "Merge branch"), and reads naturally as a command describing what applying this commit *does* — a convention that keeps a mixed-author log style-consistent.

Example: Keeping Messages Imperative

bash 
git commit -m "Add login validation"

Referencing Issues and Pull Requests

Writing Closes #15 (or Fixes, Resolves) in a commit or PR description isn't just documentation — GitHub, GitLab, and similar platforms parse those exact keywords and automatically close the referenced issue the moment the commit merges.

Example: Referencing Issues and Pull Requests

bash 
git commit -m "Fix broken image upload" -m "Closes #15"

Amending a Commit Message

git commit --amend opens your last commit's message in the editor for you to fix, replacing the commit entirely rather than adding a new one — but only do this before pushing, since amending a pushed commit changes its hash and requires a force push to sync.

Example: Amending a Commit Message

bash 
git commit --amend -m "Fix typo in login form label"
Related Topics

Git Best Practices · Git Security Best Practices · Git amend Commit · Git commit Command

{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}
Common Mistakes
  1. Writing a long subject line over about 50 characters, which gets cut off in git log --oneline and hosting UIs.
  2. Skipping the blank line between the subject and body, so tools may treat the body as part of the title.
  3. Writing in the past tense such as Added login instead of Add login, which does not match Git's own messages like Merge branch.
🔒

Chapter Quiz — Complete all 6 topics to unlock

0/6 topics done

Complete these topics first:

← Previous Lesson Git Best Practices Next Lesson → Git Security Best Practices

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.