git-workflow

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Git Workflow Skill

Git工作流Skill

Non-Negotiable Rules

不可违反的规则

Create commits only when explicitly prompted.
Push only after explicit permission for that push operation.
Never add
```
Co-Authored-By:
```
,
```
Made-By:
```
, or any other trailer that attributes an AI tool to a commit.
Preserve user changes. Do not stage, revert, or rewrite unrelated work.
Do not use
```
git add .
```
or
```
git add -A
```
blindly. Stage only the intended paths or hunks.
Never use
```
git push --force
```
. Use
```
git push --force-with-lease
```
only after discussing the risk and receiving command-specific permission.

仅在明确收到指令时创建提交。
仅在获得该推送操作的明确许可后再推送。
切勿在提交中添加
```
Co-Authored-By:
```
、
```
Made-By:
```
或任何其他将AI工具列为贡献者的尾部信息。
保留用户的更改。请勿暂存、回退或重写无关的工作内容。
切勿盲目使用
```
git add .
```
或
```
git add -A
```
。仅暂存目标路径或代码块。
切勿使用
```
git push --force
```
。仅在讨论风险并获得该命令的明确许可后，方可使用
```
git push --force-with-lease
```
。

Branch Naming

分支命名

Create branches using the pattern:

<TICKET-NUMBER>-<what-problem-is-fixed>

For projects without ticket systems, use the pattern:

<prefix>/<what-problem-is-fixed>

bash

undefined

分支命名遵循以下格式：

<工单编号>-<修复的问题描述>

对于没有工单系统的项目，使用以下格式：

<前缀>/<修复的问题描述>

bash

undefined

With ticket numbers

带工单编号的示例

git checkout -b PROJ-123-fix-login-timeout git checkout -b FEAT-456-add-user-export git checkout -b BUG-789-handle-null-response

Without ticket numbers (use prefix)

无工单编号的示例（使用前缀）

git checkout -b fix/login-timeout git checkout -b feat/add-user-export git checkout -b chore/update-dependencies

Bad examples

错误示例

git checkout -b fix-stuff git checkout -b new-feature git checkout -b johns-branch


Keep ticket IDs in the project's normal casing. Write the descriptive slug in lowercase with hyphens.

git checkout -b fix-stuff git checkout -b new-feature git checkout -b johns-branch


工单编号保持项目常用的大小写格式。描述部分使用小写字母，并用连字符分隔。

Commit Workflow

提交工作流

Before proposing or creating a commit, inspect the actual Git state:

bash

git status --short
git diff
git diff --cached

Use the diff that will actually be committed:

If changes are already staged, base the commit message on
```
git diff --cached
```
.
If no changes are staged and the user asked you to commit, stage only the intended files or hunks, then re-check
```
git diff --cached
```
.
If staged and unstaged changes both exist, keep the commit message scoped to staged changes and call out unstaged changes separately.
Never infer the commit message from file names, branch names, or prior discussion alone.

在提议或创建提交前，检查当前Git状态：

bash

git status --short
git diff
git diff --cached

根据实际要提交的差异内容操作：

如果更改已暂存，提交信息基于
```
git diff --cached
```
的内容编写。
如果没有暂存的更改且用户要求提交，仅暂存目标文件或代码块，然后重新检查
```
git diff --cached
```
的内容。
如果同时存在已暂存和未暂存的更改，提交信息仅针对已暂存的更改，并单独说明未暂存的更改。
切勿仅通过文件名、分支名或之前的讨论来推断提交信息。

Commit Message Format

提交信息格式

Structure commits as:

"<TICKET-NUMBER>: What are the main changes and why"

If the ticket number is not found in the branch name, ask for it explicitly. If the project does not use tickets, use conventional commit prefixes instead:

```
fix:
```
- Bug fixes
```
feat:
```
- New features
```
chore:
```
- Maintenance tasks (refactoring, dependencies, config)
```
wip:
```
- Work in progress (multiple related changes not yet complete)

bash

undefined

提交信息格式为：

"<工单编号>: 主要更改内容及原因"

如果分支名中没有工单编号，需明确询问用户。如果项目不使用工单系统，则使用约定式提交前缀：

```
fix:
```
- 修复Bug
```
feat:
```
- 新增功能
```
chore:
```
- 维护任务（重构、依赖更新、配置调整）
```
wip:
```
- 进行中工作（多项相关更改尚未完成）

bash

undefined

With ticket numbers

带工单编号的示例

git commit -m "PROJ-123: Fix session timeout by extending token TTL to 24 hours" git commit -m "FEAT-456: Add CSV export for user data with pagination support" git commit -m "BUG-789: Handle null API response in order processing"

Without ticket numbers (use conventional prefixes)

无工单编号的示例（使用约定式前缀）

git commit -m "fix: resolve session timeout by extending token TTL to 24 hours" git commit -m "feat: add CSV export for user data with pagination support" git commit -m "chore: update dependencies to latest versions" git commit -m "wip: initial implementation of payment processing"

Bad examples

错误示例

git commit -m "fix bug" git commit -m "updates" git commit -m "WIP"

undefined

git commit -m "fix bug" git commit -m "updates" git commit -m "WIP"

undefined

Message Proportionality

提交信息的适配性

Make commit messages proportional to changes:

Small changes (typos, minor fixes) = short, concise messages
Large changes (new features, major refactoring) = detailed messages

bash

undefined

提交信息应与更改内容的规模相匹配：

小更改（拼写错误、微小修复）= 简短、简洁的信息
大更改（新增功能、重大重构）= 详细的信息

bash

undefined

Small change - short message

小更改 - 简短信息

git commit -m "PROJ-123: Fix typo in error message"

Large change - detailed message

大更改 - 详细信息

git commit -m "FEAT-456: Implement user authentication system

Add JWT token generation and validation
Create login and logout endpoints
Add password hashing with bcrypt
Include refresh token rotation
Add rate limiting for auth endpoints"

undefined

git commit -m "FEAT-456: Implement user authentication system

Add JWT token generation and validation
Create login and logout endpoints
Add password hashing with bcrypt
Include refresh token rotation
Add rate limiting for auth endpoints"

undefined

Process Flow

流程步骤

1. git status --short          # Inspect working tree state
2. git diff                    # Review unstaged changes
3. git diff --cached           # Review staged changes
4. Stage intended changes      # Only after a commit prompt
5. Re-check git diff --cached  # Confirm exactly what will be committed
6. Write the message           # Match scope to staged changes
7. git commit                  # Commit only when prompted

Keep commits focused and atomic. Do not batch unrelated changes into one commit.

1. git status --short          # 检查工作区状态
2. git diff                    # 查看未暂存的更改
3. git diff --cached           # 查看已暂存的更改
4. Stage intended changes      # 暂存目标更改（仅在收到提交指令后）
5. Re-check git diff --cached  # 重新检查git diff --cached（确认即将提交的内容）
6. Write the message           # 编写提交信息（范围与已暂存更改一致）
7. git commit                  # 创建提交（仅在收到指令时）

提交应保持聚焦且原子化。切勿将无关更改批量提交到一个提交记录中。

Push Safety

推送安全

Before asking for push permission, inspect the target:

bash

git status -sb
git remote -v
git branch --show-current
git branch -vv

State the remote, local branch, upstream branch, and exact push command. Push only after the user explicitly approves that command.

在请求推送许可前，检查目标信息：

bash

git status -sb
git remote -v
git branch --show-current
git branch -vv

说明远程仓库、本地分支、上游分支以及具体的推送命令。仅在用户明确批准该命令后再推送。",