Git Semantic Commit Cheatsheet

THE PRACTICAL GUIDE · NORMANDIN SYSTEMS

Get more from Git Semantic Commit Cheatsheet

Git Semantic Commit Cheatsheet summarizes common commit-message prefixes used to communicate the purpose of a change. Prefixes such as fix, feat, and docs help readers scan history and may feed release tooling. The convention only helps when it matches the repository's own rules and the message describes the actual change rather than a vague activity. A cheatsheet works best as a memory aid while you practice a concrete task. Read the command or syntax together with its arguments, placeholders, and surrounding context. Similar-looking options can have very different meanings, and an example written for one platform or version may need adjustment elsewhere. Keep the reference beside a small test case, use read-only examples first when possible, and check the relevant help output before applying an unfamiliar command to valuable files or a running service.

Guide updated October 13, 2026

How to use this tool

1. Identify the operation you want to perform and find the matching section of the reference. Read the whole example before copying any part of it.
2. Choose the prefix that matches the change and write a concise subject explaining the resulting behavior.
3. Review the example below and compare its expected behavior with a small sample of your own input before continuing.
4. Try the adapted example on a small test case, compare the result with the explanation, and save the command with a note about the context in which it works.

SEE IT IN PRACTICE

A worked example

fix: handle empty search results

A commit subject identifying a bug fix and its concrete effect

The message says what behavior changed, making the history easier to understand than a subject such as update code.

Choose the prefix from the final change

A subject should describe the resulting behavior or maintenance action, not the activity of editing files. A fix resolves a defect, a feature adds capability, and a documentation change updates explanatory material according to the repository's convention. If the work changed scope during development, rewrite the subject to match the final diff. A concise subject such as fix: preserve empty filter values is more informative than fix: update code because it tells a reader what to investigate in history.

Conventions can drive automation

Some release systems interpret prefixes, scopes, and breaking-change markers to calculate versions or generate notes. Follow the repository's actual convention rather than assuming every semantic-message style has identical rules. A breaking-change marker should describe a real compatibility change and be accompanied by useful context. Keep each commit focused enough that its subject is accurate. If a commit mixes unrelated changes, improving the message may not be enough; the underlying change may need to be separated for review.

When this tool is useful

• Write a clearer commit subject
• Review a repository's message convention
• Understand how prefixes communicate change intent

Tips for a better result

• Compare the message with the final diff and avoid promising a feature or fix that the commit does not contain.
• Replace example paths, identifiers, and names deliberately. Copying a reference command unchanged can target a different file, branch, service, or environment from the one you intended.
• Keep the source and the settings used for this result together. That makes a later comparison or correction easier, especially when another person needs to reproduce the same outcome.

Frequently asked questions