75 lines
2.3 KiB
Markdown
75 lines
2.3 KiB
Markdown
# 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 进行版本管理的项目
|
||
- 团队协作开发流程
|
||
- 开源项目贡献
|