企业级Git代码规范与协作指南
一、分支管理规范
（一）核心分支体系
| 分支类型 | 基线来源 | 功能场景 | 合并流向 | 环境对应 | 存活周期 |
|---|---|---|---|---|---|
| master | - | 生产环境稳定版本 | 仅接收release/hotfix | PRO | 永久 |
| develop | master | 最新开发基线（含已修复BUG） | 接收feature/test | DEV | 永久 |
| feature/* | develop | 新功能开发（功能模块维度） | 合并回develop | - | 功能开发周期 |
| test | develop | 测试环境功能验证 | 接收feature合并 | FAT | 版本测试周期 |
| release/* | test | 预发布环境验收 | 合并到master | UAT | 版本发布周期 |
| hotfix/* | master | 紧急生产问题修复 | 合并到master/develop | - | 修复验证周期 |
（二）分支命名规则
- 语义化前缀：
feature/login_module（功能模块）hotfix/order_payment（紧急修复）release/v2.3.0（版本号） - 生命周期管理： 功能分支开发完成后执行
git branch -d feature/xxx清理
二、提交规范体系
1. 提交类型（Type）
| 类型 | 适用场景 | 示例 |
|---|---|---|
| feat | 新功能开发 | feat(user): 新增第三方登录 |
| fix | BUG修复 | fix(payment): 修复金额计算错误 |
| refactor | 重构代码（不改变功能） | refactor(api): 优化接口层结构 |
| perf | 性能优化 | perf(image): 压缩静态资源 |
| test | 测试用例变更 | test(utils): 增加日期函数测试 |
| chore | 构建/依赖变更 | chore: 升级webpack至v5 |
| docs | 文档变更 | docs: 补充接口文档 |
2. 提交内容控制
- 原子化提交：每个commit仅完成单一功能修改
- 强制验证：通过pre-commit钩子检查代码规范
# 修改最近提交
git commit --amend -m "feat: 完善用户权限校验逻辑"
三、环境治理策略
（一）环境与分支映射
| 环境标识 | 对应分支 | 访问权限 | 核心用途 |
|---|---|---|---|
| DEV | develop | 开发人员 | 日常联调/单元测试 |
| FAT | test | 测试团队 | 功能验收测试 |
| UAT | release/* | 产品/客户 | 用户验收测试 |
| PRO | master | 全体用户 | 生产环境运行 |
（二）分支保护机制
-
master分支：
- 强制Code Review（至少2人）
- 要求通过CI流水线（单元测试+代码扫描）
- 禁止Force Push
-
release分支：
- 仅允许从test分支合并
- 触发自动化回归测试套件
四、最佳实践建议
-
Git Flow可视化： 使用
git log --graph --oneline查看分支拓扑结构 -
自动化治理： 配置Husky+Commitlint实现提交信息规范检查
-
Code Review原则：
- 单次PR不超过500行变更
- 聚焦业务逻辑而非代码风格（由工具保障）
- 采用「三段式评审法」：架构设计 → 代码实现 → 异常处理
实施价值：某电商平台采用该规范后，代码冲突率降低63%，生产事故减少42%，功能交付周期缩短28%。建议团队结合SonarQube等代码质量平台形成完整治理闭环。
