rules-skills/rules/workflow/git-workflow.md

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 中记录版本变更。

示例

提交信息

# 正确
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"

分支操作

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

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

适用范围

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