第八章：Git 协作：分支、提交、PR、审阅摘要

8.1 目标：让改动可追溯、可审阅、可回滚

工程协作的核心不是“改得多快”，而是：

• 变更范围清晰
• 审阅成本可控
• 回滚路径明确

Trae 产出的变更越“像一个资深同事提交的 PR”，团队收益越稳定。

8.2 分支策略：先隔离风险

建议把这句话写进每个任务：

请在新分支上完成改动（例如 fix/<topic> 或 feat/<topic>），不要直接改 main/master。

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

如果一个提交里混合了修 bug + 重构 + 格式化，审阅会非常困难。推荐拆分：

• 提交 1：最小修复/最小功能
• 提交 2：补测试
• 提交 3：重构清理（可选）

并要求每个提交都能通过验收命令。

8.4 PR 描述模板（可直接复制）

## 变更内容
- …

## 为什么这样改
- …

## 风险与回滚
- …

## 验证
- [ ] tests：…
- [ ] lint/typecheck：…
- [ ] build：…

8.5 让 Trae 做“预审”

发 PR 前，让 Trae 以严格 reviewer 视角再看一遍通常很值：

请作为严格 reviewer 审阅这次变更：
1) 找潜在 bug 与边界条件遗漏
2) 找命名/风格不一致
3) 给最小修复建议（不要大重构）

8.6 本章小结

把 Trae 接入 Git 协作的关键是：

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

下一章进入自动化：把 CI 失败分析、PR 预审、依赖巡检做成可复用流程。