git-workflow · Git 工作流规范

规范化日常 Git 操作，让提交历史干净、PR 描述完整、分支命名一致。

流程

1. 提交代码（commit）

分析暂存区变更，生成符合 Conventional Commits 的 message：

git diff --cached --stat          # 变更范围
git diff --cached --name-only     # 受影响文件

格式：

<type>(<scope>): <简短描述>

<详细说明 — 做了什么、为什么、影响范围>

type 选择：

原则：

• subject 用祈使句：add 不用 added/adds，中文用动词开头
• scope 可选但要精准：(auth) (upload) (api)
• 不超过 72 字符（英文）/ ~35 字（中文）
• 一个 commit 只做一件事
• 不提交调试代码、临时文件、注释掉的代码

输出：生成 message 后，询问确认再执行 git commit -m "..."

2. PR 描述

对比当前分支和 base 分支，生成结构化 PR：

## 做了什么
- <变更概要 1>
- <变更概要 2>

## 为什么这样做
<一句话说明动机>

## 影响范围
- 改动的模块/文件
- 是否破坏性变更：是 / 否

## 测试
- [ ] 单测通过
- [ ] 手动验证路径：<步骤>

## 截图（如有 UI 变更）
<附在这里>

原则：

• 自动从 commit history 提取变更概要
• 检测 BREAKING CHANGE 自动标注
• 关联 issue：有 #123 格式的自动链接
• 不确定"为什么"时询问用户

3. 分支命名

检查当前分支名是否符合规范，不符合则建议重命名：

规范：

<type>/<简短描述>

• 全小写，- 分隔词，不用 _
• 不以数字开头
• 不超过 40 字符

4. Pre-commit 检查清单

提交前逐项确认：

• 没有遗留 console.log / debugger / TODO 标记
• 没有注释掉的代码
• 没有临时测试文件
• 相关测试已更新且通过
• 新依赖已记录在 package.json / Cargo.toml 等
• 没有多余的格式化改动（只改了你能解释的）