git-commit-specification

Git Commit Conventions

Applicable Scenarios

• Writing a commit message
• Determining which category this change should be classified as, such as feat、fix、refactor and so on
• Organizing commit boundaries to avoid stuffing multiple unrelated types of changes into one commit
• Performing the most basic self-check before committing

Inapplicable Scenarios

• Discussing specific business implementation plans
• Modifying Git history or performing high-risk Git operations
• Only creating a branch, without involving the commit conventions themselves

Quick Guidance

1. This skill focuses on "how a commit expresses the intent of the change", not a comprehensive Git command reference.
2. A commit message should prioritize expressing the nature and purpose of the change. Common types include:
   • feat: adding new capability
   • fix: fixing a problem
   • refactor: refactoring without changing external behavior
   • perf: performance optimization
   • test: adding or adjusting tests
   • docs: documentation changes
   • chore: build, configuration, and toolchain maintenance
3. Keep the commit message format concise and stable, for example:feat: 添加流水线模板功能 #1234
4. One commit should express only one main intent; if multiple independent purposes are mixed in, prefer splitting the commit.
5. Before committing, do a minimal self-check first: whether the scope of changes is focused, whether sensitive information is included, and whether necessary verification has passed.
6. High-risk history-rewriting operations should not be written into the main skill as default recommendations; if truly needed, they should be judged separately according to the specific scenario.

High-Signal Rules

• The core of a commit message is to let reviewers quickly understand "why this change exists"
• Type selection should serve the intent of the change, not be applied mechanically
• Clear commit boundaries are more important than a fancy message
• Information such as issue numbers and scope markers should follow team conventions, but should not overshadow the main semantics

Key Pitfalls

• A single commit mixes features, refactoring, fixes, and formatting at the same time
• The message only contains low-information descriptions like "update" or "fix bug"
• Treating interactive, destructive, or high-risk Git operations as default conventions

Further Reading

• If preparing a PR, review context and verification results can be added on top of the current changes
• If high-risk Git history rewriting needs to be handled, judge separately according to the specific repository process, and do not expand it by default in this skill