Git Commit Messages

Feature Overview

Create clear and standardized git commit messages. Prioritize following the project's existing commit history and format conventions, then refer to the Conventional Commits standard. Ensure commit messages are concise, consistent, and easy to understand.

Quick Check Process

Step 1: Quickly Determine Project Conventions (First Use)

Execute only on first use or when project conventions are unknown:

bash

# View the last 5 commits only
git log -5 --pretty=format:"%s"

Quick Judgment:

Type names:
```
feat
```
or
```
feature
```
,
```
fix
```
or
```
bugfix
```
Language: Chinese or English
Issue reference: In subject or footer

Cache the judgment result, no need to re-analyze for subsequent commits.

Step 2: Identify Change Content

bash

# View current changes
git diff --stat

Judge whether changes belong to the same module:

If there are no unrelated contents, proceed directly to Step 3
If there are unrelated contents, refer to the processing method in the "Intelligent Change Content Recognition" section

Step 3: Check if Commit Merging is Needed

bash

git status
git log @{u}..HEAD --oneline 2>/dev/null

If there are no ahead commits, proceed directly to Step 4
If there are ahead commits, refer to the judgment method in the "Merge Similar Commits" section

Step 4: Quickly Generate Commit Message

Quickly generate messages based on cached conventions and change content, no need for detailed analysis.

Prioritize Following Existing Project Conventions

Check Project Commit Style

bash

# View only the last 5 commits
git log -5 --pretty=format:"%s"

Determine Project Conventions

Type names:
```
feat
```
vs
```
feature
```
,
```
fix
```
vs
```
bugfix
```
Issue reference: In subject (
```
feat: #123 xxx
```
) or footer (
```
Closes #123
```
)
Language style: Chinese or English
Format strictness: Whether strictly following a certain specification

Language Selection

Count recent commits, use Chinese if most are in Chinese, otherwise use English.

Follow Principles

If the project has clear conventions → strictly follow
If the project has no clear conventions → imitate existing style
If the project has no obvious style → use Conventional Commits standard

Commit Message Format

Conventional Commits Standard

<type>(<scope>): <subject>

<body>

<footer>

Required parts:

```
type
```
: Commit type
```
subject
```
: Short description (50-72 characters)

Optional parts:

```
scope
```
: Impact scope
```
body
```
: Detailed description
```
footer
```
: Breaking changes, references, etc.

Commit Types (type)

Prioritize using project-specific types. Refer to the following if no clear types are available:

Type	Description	Example
`feat` / `feature`	New feature	feat: add user authentication
`fix` / `bugfix`	Bug fix	fix: resolve login timeout
`docs`	Documentation change	docs: update API documentation
`style`	Code format	style: unify code indentation
`refactor`	Refactoring	refactor: extract common methods
`perf`	Performance optimization	perf: optimize query performance
`test`	Test-related	test: add unit tests
`chore`	Build/toolchain	chore: update dependency versions

Subject Rules

Use imperative mood (present tense):
```
add
```
instead of
```
added
```
or
```
adds
```
Lowercase first letter (English) or normal case (Chinese)
No punctuation at the end
Limit to 50-72 characters
Clearly describe what was done

Body Rules

Explain what was done and why
Limit each line to 72 characters
Use imperative mood
Provide sufficient context

Footer Rules

Breaking changes:

BREAKING CHANGE: API endpoints now require authentication

Reference Issue/PR:

Closes #123
Refs #456

Scope Usage Specifications

Scope specifies the impact range of the commit.

Common Scopes:

Project Type	Scope Examples
Web Application	`api` , `ui` , `auth` , `db`
Library/Framework	`core` , `utils` , `types`
Mobile Application	`ios` , `android` , `shared`
DevOps	`ci` , `docker` , `deploy`

Format Rules:

Use lowercase letters
No more than 10-15 characters
Omit scope if unsure

Intelligent Change Content Recognition

Analysis Principles

Identify main modules: Analyze all changed files to find the module/business most of the content belongs to
Identify unrelated content: Find changes completely unrelated to the main module
Suggest commit strategy: Commit main module content, leave unrelated content for later

Judgment Criteria

Belong to the same module/business (recommend committing together):

Different parts of the same feature (API, types, utility functions)
Feature development + related documentation
Feature development + related configuration
Feature development + dependency updates

Completely unrelated (recommend not committing for now):

Changes in different business modules (user module + order module)
Code + deployment configuration files
Code + CI/CD configuration
Code + .gitignore and other configurations

Processing Logic

Case 1: All changes belong to the same module

Commit directly, no prompt needed.

Case 2: Most changes belong to the same module, with a small amount of unrelated content

Changed content:
- src/api/users.ts (user module)
- src/types/user.ts (user module)
- src/api/orders.ts (order module, unrelated)

Main module: User module

Unrelated changes (recommend not committing for now):
- src/api/orders.ts (order module, unrelated)

Skip unrelated content and only commit user module-related changes? (y/n)

Case 3: Changes in multiple modules are comparable

Changed content:
- src/api/users.ts (user module, 50 lines)
- src/types/user.ts (user module, 20 lines)
- src/api/orders.ts (order module, 60 lines)
- src/types/order.ts (order module, 30 lines)

User module: 70 lines
Order module: 90 lines

Order module has more changes, recommend committing order module-related content:
- src/api/orders.ts
- src/types/order.ts

Commit only order module? (y/n)
Or commit all? (all)

Processing Method

bash

# Only stage files related to the main module
git add src/api/users.ts src/types/user.ts
git commit -m "feat(api): add user interface"

# Unrelated files are not staged, leave for later processing

Merge Similar Commits

Pre-check

Perform merge judgment only when there are ahead commits:

bash

# Check if there are ahead commits
AHEAD=$(git rev-list --count @{u}..HEAD 2>/dev/null || echo "0")

if [ "$AHEAD" -eq 0 ]; then
  # No ahead commits, create new commit directly
  echo "Local is synchronized with remote, create new commit directly"
else
  # There are ahead commits, perform merge judgment
  echo "There are $AHEAD ahead commits locally, check if merging is needed"
fi

Quick Similarity Judgment

Only need to view the last commit message and current changes:

bash

# Get the last commit
LAST_COMMIT_MSG=$(git log -1 --pretty=format:"%s")

# View current changes
git diff --stat

Judgment Criteria:

Condition	Action
Same type + same module files	Ask if merging is needed
Fix for the same bug	Ask if merging is needed
Continuous documentation updates	Ask if merging is needed
Other cases	Do not merge

Merge Method

bash

# Stage current changes
git add <files>

# Merge into the last commit
git commit --amend --no-edit

# Or update the commit message
git commit --amend -m "Updated commit message"

Practical Examples

Basic Examples

English:

feat: add dark mode support
fix: resolve login timeout issue
docs: update README with new installation steps

Chinese:

feat: 添加深色模式支持
fix: 修复登录超时问题
docs: 更新安装指南

Examples with Scope

feat(auth): implement OAuth2 login
fix(ui): correct button alignment on mobile
refactor(db): optimize user query performance

Chinese Examples:

feat(auth): 实现 OAuth2 登录
fix(ui): 修复移动端按钮对齐问题
refactor(db): 优化用户查询性能

Examples with Body

feat(api): add pagination support

Implement pagination for list endpoints:
- Add `page` and `limit` query parameters
- Return total count and pagination metadata
- Update documentation with examples

Closes #42

fix(auth): resolve token expiration issue

The JWT token expiration was not being checked
correctly, allowing expired tokens to be used.
Added proper validation middleware.

Fixes #128

Breaking Change Examples

feat(api): remove deprecated endpoints

Remove v1 endpoints in favor of v2:
- DELETE /api/v1/users
- DELETE /api/v1/posts

BREAKING CHANGE: v1 endpoints are no longer available.
Please migrate to v2 endpoints.

Migration guide: docs/migration.md

feat(auth): require email verification

All new users must verify their email before
accessing the platform.

BREAKING CHANGE: Email verification is now mandatory.
Existing users are grandfathered in.

Common Issues

Issue: Commit message is too long

Solution: Simplify the description and put detailed information in the body.

feat: add comprehensive user authentication system with OAuth2 support and token management

↓

feat: add user authentication

Implement OAuth2 login and token management system

Issue: Difficulty in selecting type

Quick Decision:

New feature → feat
Bug fix → fix
Refactoring (no functional change) → refactor
Performance optimization → perf
Documentation → docs
Format adjustment → style
Testing → test
Others → chore

Issue: Unsure about Scope

Guidelines:

Cross-module changes → omit scope
Single module change → use module name as scope
Unsure → omit scope

Notes

Local operations only: This skill is only responsible for creating commits, no push operations are performed
Maintain atomicity: One commit does only one thing
Clear commit history: Able to reproduce the development process
Avoid sensitive information: Do not commit passwords, keys, tokens
Follow project conventions: Strictly follow conventions if the project has them

git-commit

NPX Install

Tags

SKILL.md Content (Chinese)

Git Commit Messages

Feature Overview

Quick Check Process

Step 1: Quickly Determine Project Conventions (First Use)

Step 2: Identify Change Content

Step 3: Check if Commit Merging is Needed

Step 4: Quickly Generate Commit Message

Prioritize Following Existing Project Conventions

Check Project Commit Style

Determine Project Conventions

Language Selection

Follow Principles

Commit Message Format

Conventional Commits Standard

Commit Types (type)

Subject Rules

Body Rules

Footer Rules

Scope Usage Specifications

Intelligent Change Content Recognition

Analysis Principles

Judgment Criteria

Processing Logic

Processing Method

Merge Similar Commits

Pre-check

Quick Similarity Judgment

Merge Method

Practical Examples

Basic Examples

Examples with Scope

Examples with Body

Breaking Change Examples

Common Issues

Issue: Commit message is too long

Issue: Difficulty in selecting type

Issue: Unsure about Scope

Notes