git commit: Writing Good Commit Messages, Atomic Commits, and Best Practices

`git commit` is the command that permanently saves your staged changes as a new snapshot in the repository's history. But typing the command itself is the easy part — the real skill, and the one that separates a genuinely useful project history from a confusing mess, is writing good commit messages and structuring atomic commits. This lesson covers both the mechanics of the command and the professional conventions that make Git history something your team (and future you) will actually thank you for.

Learning Objectives

Use git commit -m to create a commit with an inline message.
Explain the principle of atomic commits and why they matter.
Write clear, conventional commit messages following industry best practices.
Use git commit --amend to correct the most recent commit.

Key Terms to Know Before Learning git commit

Commit: A permanent, saved snapshot of the staged changes in a repository's history, along with metadata (author, timestamp, message).
Atomic commit: A commit that contains one single, logical, self-contained change — not a mix of unrelated fixes bundled together.
Commit message: A short, human-readable description explaining what changed and why, attached permanently to each commit.
Conventional Commits: A widely adopted convention for structuring commit messages with a type prefix (e.g., feat:, fix:, docs:) to make history machine-readable and consistent.
git commit --amend: A command that modifies the most recent commit — its message, its staged content, or both — rather than creating a brand-new commit.

How git commit Actually Works

The most basic form of committing is:

```
git commit -m "Add user login form"
```

The `-m` flag lets you supply a short commit message inline. Running `git commit` without `-m` instead opens your configured default editor (see Lesson 5), where you can write a longer, multi-line message — useful when a change needs more explanation than a single line allows.

**Atomic commits** are the professional standard for structuring changes. An atomic commit contains exactly one logical, self-contained change — for example, 'Fix null pointer error in checkout flow' as its own commit, separate from 'Add dark mode toggle to settings page'. This matters enormously in practice: if a bug is later found, tools like `git bisect` can pinpoint the exact commit that introduced it, but only if commits are small and focused. A commit that bundles ten unrelated changes together makes it far harder to understand, review, or safely revert individual pieces of work.

**Writing good commit messages** follows a small number of widely respected conventions:

1. Use the **imperative mood** — write 'Add feature' or 'Fix bug', not 'Added feature' or 'Fixes bug'. This mirrors the convention Git itself uses in its own generated messages (e.g., 'Merge branch').
2. Keep the first line (the **subject line**) short — ideally under about 50 characters — and capitalized, without a trailing period.
3. If more detail is needed, leave a blank line after the subject, then write a longer body explaining *what* changed and, more importantly, *why* — the diff itself already shows *what* changed line by line, so the message's real value is context and reasoning.
4. Many teams adopt the **Conventional Commits** format, prefixing messages with a type such as `feat:` (new feature), `fix:` (bug fix), `docs:` (documentation only), `refactor:` (code change with no behavior change), or `chore:` (maintenance tasks). This makes history scannable and even machine-parseable for automated changelog generation.

Finally, mistakes happen — you commit, then immediately notice a typo in the message or realize you forgot to stage one small file. `git commit --amend` lets you fix the most recent commit without creating a new one: running `git commit --amend -m "Corrected message"` replaces the previous commit's message, and if you `git add` an additional file first, `--amend` will fold that into the previous commit as well. This should only be used on commits that haven't been shared (pushed) with others yet, since amending rewrites that commit's history.

git commit: Visual Walkthrough

Draw a 'bad commit' box on the left containing a jumbled list: 'Fix typo, add dark mode, refactor auth, update README, fix bug' all under ONE commit labeled 'wip'. Draw an arrow labeled 'atomic commit principle' pointing to a 'good commits' box on the right showing FIVE separate small commit boxes stacked vertically, each with a clear message: 'fix: correct typo in header', 'feat: add dark mode toggle', 'refactor: simplify auth logic', 'docs: update README setup steps', 'fix: resolve checkout null pointer error'.

git commit: Quick Reference Table

Commit Message Style	Example	Quality
Vague / non-descriptive	"update", "fix stuff", "wip"	Poor — gives no useful context to future readers
Wrong mood / tense	"Added the login button"	Weak — inconsistent with imperative convention
Good imperative, concise	"Add login button to navbar"	Good — clear, scannable, follows convention
Conventional Commits format	"feat: add login button to navbar"	Best — clear, typed, supports automated tooling

git commit: Command Syntax and Examples

# Stage a change, then commit with an inline message
git add login.js
git commit -m "feat: add client-side validation to login form"

# Commit without -m to open your default editor for a longer message
git commit
# (opens editor — write subject line, blank line, then a detailed body)

# Fix the most recently created commit's message
git commit --amend -m "fix: correct client-side validation error message"

# Stage a forgotten file and fold it into the previous commit (no new commit created)
git add forgotten-file.js
git commit --amend --no-edit

Breaking Down the git commit Example

The first commit uses the Conventional Commits format (`feat:`) with a concise, imperative subject line describing exactly what was added. The second example shows opening the default editor for a more detailed message when a one-liner isn't enough. `git commit --amend -m "..."` demonstrates correcting a mistaken message on the most recent commit rather than creating a cluttered extra commit just to fix a typo. `git commit --amend --no-edit` shows folding a forgotten staged file into the previous commit while keeping its existing message unchanged — a common real-world fix-up pattern.

How git commit Is Used on Real Engineering Teams

Major open-source projects like Angular and Vue.js formally enforce the Conventional Commits specification, using tooling to auto-generate changelogs and determine semantic version bumps directly from commit message prefixes.
Code review culture at most engineering-mature companies explicitly evaluates commit quality — reviewers frequently ask contributors to split a large, non-atomic commit into smaller, logically separated ones before merging.
Incident response teams rely heavily on git bisect combined with atomic commit history to rapidly pinpoint the exact commit that introduced a production bug, which is impossible to do efficiently with large, mixed-purpose commits.
Automated release tools (like semantic-release) parse Conventional Commits messages directly from project history to automatically determine whether a new release should be a patch, minor, or major version bump.

git commit Interview Questions and Answers

Q1. What makes a commit 'atomic' and why does it matter?

An atomic commit contains exactly one logical, self-contained change rather than a mix of unrelated fixes and features bundled together. This matters because it makes history easier to review, allows tools like git bisect to pinpoint exactly which change introduced a bug, and makes it safe to revert a single change without affecting unrelated work.

Q2. What are the conventions for writing a good commit message?

Write the subject line in the imperative mood (e.g., 'Add feature' not 'Added feature'), keep it concise (roughly under 50 characters), avoid a trailing period, and if more explanation is needed, add a blank line followed by a detailed body explaining why the change was made, not just what changed.

Q3. What does git commit --amend do, and when should you avoid using it?

It modifies the most recently created commit — updating its message, its staged content, or both — instead of creating a brand-new commit. It should be avoided on commits that have already been pushed and shared with others, since amending rewrites that commit's history and can cause conflicts for collaborators who already have the original version.

git commit Quiz: Test Your Understanding

1. What is an 'atomic commit'?

A commit that includes every file in the project
A commit containing one single, self-contained logical change
A commit made automatically by a script
A commit that cannot be reverted

Answer: B. A commit containing one single, self-contained logical change

Explanation: Atomic commits bundle exactly one logical change, making history easier to read, review, and safely revert or bisect.

2. Which commit message follows the recommended imperative mood convention?

"Fixed the bug"
"Fixing the bug"
"Fix the bug"
"Bug was fixed"

Answer: C. "Fix the bug"

Explanation: The imperative mood ('Fix', 'Add', 'Update') is the widely recommended convention, mirroring how Git's own auto-generated messages (like merge commits) are phrased.

3. What does git commit --amend do?

Creates a brand new commit on top of the last one
Deletes the most recent commit permanently
Modifies the most recently created commit
Merges two branches together

Answer: C. Modifies the most recently created commit

Explanation: git commit --amend updates the most recent commit — its message, its included changes, or both — rather than adding a new commit to history.

4. Which is a key reason to avoid amending a commit that has already been pushed?

It will permanently delete the remote repository
It rewrites history, which can cause conflicts for collaborators who already have the original commit
Amending is technically impossible after a push
It automatically creates a merge conflict

Answer: B. It rewrites history, which can cause conflicts for collaborators who already have the original commit

Explanation: Amending changes a commit's hash and content, so anyone who already pulled the original version will have a mismatched history, leading to confusing conflicts when syncing.

git commit: Common Mistakes Beginners Make

Writing vague commit messages like 'update' or 'fix stuff' that give no useful context to future readers of the history.
Bundling multiple unrelated changes (a bug fix, a new feature, and a formatting cleanup) into a single large commit.
Using git commit --amend on commits that have already been pushed and shared with teammates, causing confusing history conflicts.
Forgetting that git commit only saves what's currently staged — unstaged changes are silently left out of the new commit.

git commit: Exam-Ready Quick Notes

git commit -m "message" creates a commit with an inline message; without -m, it opens the default editor.
Atomic commit = one logical, self-contained change per commit.
Commit message convention: imperative mood, concise subject line, optional detailed body after a blank line.
git commit --amend modifies the most recent commit; avoid using it on already-pushed commits.

git commit: Key Takeaways

git commit permanently saves whatever is currently staged as a new snapshot with an author, timestamp, and message.
Atomic, focused commits make project history dramatically easier to review, debug, and safely revert.
Clear, imperative-mood commit messages — ideally following a convention like Conventional Commits — turn history into a genuinely useful project record.

Frequently Asked Questions About git commit

Q1. What does git commit do?

It takes everything currently in the staging area and permanently saves it as a new snapshot in the repository's history, along with an author, timestamp, and the message you provide.

Q2. What is an atomic commit and why should I care?

An atomic commit contains one single, focused, logical change rather than several unrelated changes bundled together. It matters because it makes your project history easier to understand, review, and safely undo or debug later.

Q3. How should I write a good commit message?

Use the imperative mood (e.g., 'Add', 'Fix', 'Update'), keep the first line short and to the point, and if the change needs more explanation, add a blank line followed by a longer description focused on why the change was made.

Q4. What is git commit --amend used for?

It lets you modify the most recently created commit — for example, to fix a typo in its message or to add a file you forgot to stage — instead of creating an entirely new commit for a tiny correction.

Q5. Is it safe to use git commit --amend on any commit?

It's safe on commits that haven't been pushed or shared with anyone else yet. Avoid amending commits that have already been pushed to a shared remote, since it rewrites that commit's history and can cause conflicts for collaborators.

Summary

`git commit` saves the currently staged changes as a new, permanent snapshot in the repository's history, using `-m` for an inline message or opening the default editor for a longer one. Professional Git usage emphasizes atomic commits — each containing exactly one logical, self-contained change — because this makes history easier to review, debug, and safely revert, and enables tools like `git bisect` to pinpoint exactly which change introduced a problem. Well-written commit messages use the imperative mood, a concise subject line, and (when needed) a detailed body explaining why a change was made. `git commit --amend` allows correcting the most recent commit's message or contents, but should be avoided on commits already shared with others.