Git 协作与分支策略

0. 引言

Git 是事实上的版本控制标准，但真正影响团队效率的不是"会不会 git add"，而是分支策略、提交规范、发布节奏与冲突处理方式。经典 Git Flow 分支繁多、流程沉重，对交付频率高、需求迭代快的团队并不友好。本章介绍更适合中小型后端团队的轻量主干协作模型，并给出提交规范与冲突处理的最佳实践。

1. 分支模型：轻量主干协作

相比经典 Git Flow（master/develop/feature/release/hotfix 五分支常驻），轻量主干模型：

• 分支更少：没有长期并行的 develop 与 master，减少合并成本；
• 发布更频繁：main 随时可发布，契合持续交付；
• 职责更清晰：只有"功能、发布、热修"三类临时分支。

2. 核心协作原则

• 小步提交：提交原子化（一个提交只做一件事），降低冲突面，便于回滚与审查；
• 尽早合并：功能分支短生命周期，减少长分支漂移（分支拖得越久，合并成本指数上升）；
• PR 做审查：用 Pull Request 触发代码审查，而不是把主分支当个人备份区；
• 不在线上分支开发：main 只接收合并，不直接写代码。

3. 常用命令流

git checkout -b feature/user-profile   # 从 main 拉功能分支
git add .
git commit -m "feat: add user profile query api"
git fetch origin
git rebase origin/main                 # 合并前先变基到最新主干
git push origin feature/user-profile   # 推送后发起 PR

merge 与 rebase 的选择：

实践建议：个人功能分支用 rebase 保持线性，合并回主干用 merge 保留发布节点；需要精确回溯"何时合入"用 merge commit，追求整洁历史用 rebase。

4. 提交信息规范

规范化的提交信息让 git log、git bisect 与自动生成 changelog 成为可能。

5. 常见误区

• 功能分支挂几周不合并：漂移越大冲突越重，合并成本随周期指数增长；
• 混提交：格式化、重构、功能改动混在一个提交里，无法单独回滚；
• 冲突直接覆盖：不理解冲突双方语义就强制覆盖，是线上事故的常见源头（先看 git log 双方意图，必要时当面沟通）；
• 在线上分支直接开发：绕过审查与发布流程，破坏可追溯性。

6. 小结

• 模型：main 可随时发布 + feature/release/hotfix 临时分支，轻量主干优于经典 Git Flow；
• 节奏：小步提交、尽早合并、PR 审查三原则，把冲突消灭在萌芽；
• 历史：个人分支 rebase 线性化，主干合并保留节点，二者按需取用；
• 规范：feat/fix/refactor/docs/chore 前缀 + 原子化提交，是团队协作的通用语言。

下一章讲解前端私有化 NPM 仓库管理——依赖私有化、版本锁定与构建提速的工程实践。