规范的目标不是形式整齐
Git 规范应该回答三个问题：谁能合并、什么变化需要评审、出现问题如何定位。只在文档里写“请使用规范提交”没有约束力；更有效的做法是把规则映射到 hook、CI 和保护分支。
建议先约定分支：main 只接收发布就绪代码，feature/* 承载短周期任务，fix/* 处理线上问题。分支名应包含工单号，例如 feature/WEB-123-search-filter，避免出现无法追踪的 test2。
提交消息的可解析格式
采用 Conventional Commits 的简化版：
<type>(<scope>): <summary>
[optional body]
type 可取 feat、fix、refactor、test、docs、build、chore。summary 用祈使句，长度不超过 72 个字符。破坏性变更在正文写 BREAKING CHANGE:，这样发布工具才能正确生成变更日志。
CI 中可用正则做第一层检查：
commitlint:
image: node:22-alpine
script:
- npm ci
- npx commitlint --from "$CI_MERGE_REQUEST_DIFF_BASE_SHA" --to "$CI_COMMIT_SHA"
规则检查格式，不判断技术内容；内容质量仍由代码评审负责。
变更范围与评审人
用 CODEOWNERS 将目录和责任人绑定：
/src/payment/ @payments-team
/infra/ @platform-team
*.md @docs-owner
当一次提交同时跨越多个领域，评审人应覆盖所有匹配规则。对于数据库迁移、权限策略和公共 SDK，建议在 CI 中增加“必须至少两名审批人”的保护条件。不要把审批条件藏在机器人评论里，平台分支保护才是最终门槛。
合并策略和可追溯发布
小而独立的提交方便 git bisect，但合并到主干时可使用 squash，确保一个需求对应一个发布变更。合并请求标题携带工单号，发布标签使用不可变的语义版本，如 v2.4.1。发布后把标签、构建产物摘要和部署环境写入变更记录，故障时能够回答“哪个版本在哪个环境运行”。
推荐的发布检查：
- 工作区无未提交文件，版本号与标签一致。
- 单元测试、静态检查和构建全部通过。
- 数据库迁移有前向脚本和回滚说明。
- 依赖锁文件已提交且没有临时调试配置。
处理紧急修复
线上修复从 main 创建 fix/INC-xxx，修复提交必须包含复现步骤和影响范围。发布后把同一提交拣回仍在开发的长期分支，避免下次合并重新引入缺陷。紧急并不意味着跳过审计：至少保留一名值班评审人和一次生产验证记录。
边界条件
- 自动格式化产生的大提交会掩盖逻辑变化，应单独提交。
- 重命名和删除文件要在评审描述中显式列出。
- 生成文件可以排除在评审之外，但必须记录生成命令与工具版本。
- 规则升级应先以警告运行一周，再切换为阻断，避免一次性冻结团队。
总结
Git 规范的价值在于可追溯和可恢复。分支名关联工单，提交消息可解析，CODEOWNERS 负责领域审批，CI 检查格式与构建，发布标签锁定可复现版本。把规则放到工具链里，团队才不会依赖个人记忆。
Git CI/CD 代码评审 工程规范 DevOps
