第八章：Git 工作流：分支、提交、PR、代码评审协作

8.1 Claude Code 的正确定位：帮你产出“可审阅的变更集”

Git 工作流的目标不是“提交更多 commit”，而是：

• 让改动可追溯
• 让审阅可聚焦
• 让回滚可控

所以你可以把 Claude Code 当作“会写代码的结对伙伴”，但合入前依然要：

• /diff 审阅
• 跑测试与 lint
• 明确 commit message 与变更范围

8.2 分支策略：先把风险隔离

推荐你在任务开始时明确要求：

请在新分支上完成改动，分支名格式：fix/<topic> 或 feat/<topic>。
不要直接改 main/master。

8.3 提交策略：一次提交一个主题

如果一个提交里既包含修 bug 又包含重构，审阅会非常困难。建议你要求：

提交拆分规则：
1) 修复逻辑一个提交
2) 测试补齐一个提交
3) 重构清理一个提交（可选）
每个提交都要能通过测试。

8.4 PR 描述模板（让协作成本更低）

你可以让 Claude 直接按模板输出 PR 描述：

## 变更内容
- …

## 为什么这样改
- …

## 风险与回滚
- …

## 验证
- [ ] 测试命令：…
- [ ] lint 命令：…

8.5 评审协作：让 Claude 做“预审”

在发 PR 之前，让 Claude 做一次“自我评审”通常收益很高：

请作为严格的 reviewer 审阅这次 /diff：
1) 找潜在 bug
2) 找边界条件遗漏
3) 找不一致的命名/风格
4) 给出你建议的最小改动修正

8.6 本章小结

你现在可以把 Claude Code 无缝接入团队 Git 协作：

• 新分支隔离风险
• 提交按主题拆分，审阅更轻
• PR 描述结构化，沟通更快
• 发 PR 前先做“预审”，减少来回

下一章我们把安全与隐私系统化：哪些信息绝对不能暴露、哪些命令绝对不能让它跑、以及如何建立团队基线。