git-commit-convention

name	git-commit-convention
description	Operational commit rules: when to commit, what goes in each commit, commit frequency and history management. Use when committing code, deciding commit boundaries or managing git history. Pairs with commit-format for message structure.

Git Commit Convention

For the commit message format itself (conventional commits, types, scopes, subject and body rules), see commit-format. This skill covers the operational conventions: when to commit, what goes in each commit, and how to manage history.

Commit Frequency

• Commit after each logical unit of work.
• In TDD: commit after each green + refactor cycle.
• When planning: commit the plan file itself.
• Don't batch unrelated changes into one commit.

Atomic Commits

Each commit should be one concern:

• One bug fix per commit.
• One feature step per commit.
• One refactor per commit.
• Tests and implementation in the same commit (they're one unit).

If you find yourself writing "and" in the subject line, it's probably two commits.

History

• Interactive rebase is fine for cleaning local history before push.
• Never force-push shared branches without discussion.
• Prefer --force-with-lease over --force when rewriting remote.
• Never use --amend. Make a new commit instead. Amending rewrites history and is almost never worth it. A new commit is cleaner and preserves the work trail. If the previous commit has a mistake, fix it forward with a new commit.
• Avoid WIP commits on shared branches; squash locally with interactive rebase before pushing.

When Not to Commit

• Broken tests (unless explicitly spiking or experimenting).
• Half-finished features without a clear stopping point.
• Generated files that should be in .gitignore.