7. 团队协作

这是什么：Pull Request（PR） = 一张「请看看我的修改，可否合回 main」的申请单，团队协作的标准动作是分支 → PR → 评审 → 合并。

为什么用：上一章你已经能把代码推上云端，可一把梭直接 push 到 main 的时代早就结束了——改动没评审就进主干，出了问题谁都说不清，Issue 也失去了讨论沉淀的地方。

如何用：本章走一遍协作流程全景，看清 PR 怎么发起、评论怎么留档，再把 commit 规范和分支粒度的约定立起来。

7.1 协作流程全景

① 从最新 main 分支拉出 feat_xxx
② 在分支上开发、提交（可推送备份）
③ 平台发起 Pull Request（PR）
④ CI 跑构建 / 同事 review 评论
⑤ 修改后补 commit / 或措辞修正（来自 review）
⑥ merge 进 main、删除分支

这就是 feature branch workflow——小型团队最万能、最少门槛的流程。

7.2 Pull Request 是什么

PR = 「请看看我的修改，可否合回 main」。它带来两件大事：

• 评审：视线集中在「这回的增量」上，变化清晰
• 讨论沉淀：为什么这样设计、踩了什么坑都留在评论区（团队知识库）

一个分支一张 PR，PR paired 一批 commit——这样找历史时从「这功能怎么上的线」反向阅读，特别快。

7.3 Issue：讨论与派活

• Issue：报 bug、提需求、讨论方案的「工单」
• commit message 写 fix: 修复首页白屏 (fixes #123)，platform 自动索引到 issue

7.4 强约定（越简单越持久）

1. commit message 遵守第 3 章格式（feat/fix/docs/refactor/chore）
2. 一个分支只做一件事，PR 尽量小（< 300 行阅读愉快）
3. 绝不 force push 共享分支（第 6 章）
4. 本博客明确约定更好：commit/push 前需人工确认（见 deploy.md / ai-ops.md）

7.5 动手改

1. 在 Gitee 本博客仓库开一条 Issue，写清复现步骤（对新手也是历练）
2. 建 docs_xxx 分支改文档，找到 PR 流程入口创建（private 仓库也可自查流程）
3. （若无 Merge 权限）自留 PR 观察 review 的评论样式

7.6 小结

• 团队主流 = 分支 + PR + review，单人开发也推荐（留档备查）
• Issue 是需求与讨论的「户口本」
• 命名、PR 粒度、force 限制越早养成习惯越省事

下一章：实战：本博客定版流程 🐸