# Git 工作流规范

## 规则

1. **提交粒度**：
   - 每次提交只做一件事，保持提交的原子性。
   - 避免将不相关的修改混入同一提交。
   - 提交前使用 `git diff --cached` 检查变更内容。

2. **提交信息规范**：
   - 使用 `git commit -m "<type>: <subject>"` 格式。
   - `<type>` 必须是以下之一：
     - `feature`：新功能
     - `bug`：修复 bug
     - `docs`：文档更新
     - `style`：代码格式（不影响功能）
     - `refactor`：重构
     - `test`：测试相关
     - `chore`：构建过程或辅助工具的变动
   - `<subject>` 使用祈使句，首字母小写，不超过 50 个字符。
   - 需要详细说明时，使用 `-m` 多行提交，空行分隔标题和正文。

3. **分支管理**：
   - 主分支： `master`，始终保持可部署状态。
   - 开发分支：`dev`，集成所有功能开发。
   - 功能分支：`feature/<编号>`，没有编号时使用`feature/<描述>`，从 `master`切出，完成后合并回 `master`。
   - 修复分支：`bug/<编号>`，没有编号时使用`bug/<描述>`，从 `master` 切出，完成后合并回 `master`。
   - 紧急修复：`hotfix/<描述>`，从 `master` 切出，完成后合并回 `master` 。

4. **代码审查**：
   - 合并到 `master` 前必须通过 Pull Request。
   - PR 标题遵循提交信息规范。
   - PR 描述简要描述修改内容，不要过长的提交信息。

5. **冲突处理**：
   - 优先使用 `git rebase` 保持提交历史线性。
   - 冲突解决后，确保代码可正常编译和运行。
   - 禁止在公共分支上使用 `git push --force`。

6. **标签与版本**：
   - 使用语义化版本号：`v<major>.<minor>.<patch>`。
   - 版本发布时创建对应的 tag。
   - 在 `CHANGELOG.md` 中记录版本变更。

## 示例

### 提交信息

```bash
# 正确
git commit -m "feature: add user authentication"
git commit -m "bug: resolve null pointer in order service"

# 错误
git commit -m "update"
git commit -m "Fix bug"
```

### 分支操作

```bash
# 创建功能分支
git checkout -b feature/user-login master

# 完成后合并
git checkout master
git merge --no-ff feature/user-login
```

## 适用范围

- 所有使用 Git 进行版本管理的项目
- 团队协作开发流程
- 开源项目贡献