第01章：GitHub协作全景与角色分工

第01章：GitHub协作全景与角色分工

把“代码仓库”升级为“协作系统”

本章学习目标

  • 理解 GitHub 在团队中的真实价值，而不只是存代码。
  • 明确开发、评审、测试、产品在协作链路中的职责。
  • 识别常见协作反模式，避免流程失控。

一、GitHub 不只是代码托管

在高效团队里，GitHub 承担四个核心职能：

  1. 变更管理：每个改动都有来源、讨论、审查、记录。
  2. 协作入口：Issue 定义问题，PR 承载实现，Review 保证质量。
  3. 质量门禁：CI 自动验证，不通过不合并。
  4. 发布追踪：Tag/Release 让线上版本可追溯、可回滚。

二、角色分工（RACI 思维）

角色 主要职责 常见误区
开发者 编码、补测试、提交 PR、响应 review 只改代码不写背景与测试说明
Reviewer 检查风险、边界、可维护性 只看代码风格，不看行为变化
QA 定义测试范围、回归验证 测试滞后到上线前才介入
产品/项目 明确目标、范围、验收标准 需求只讲“做什么”，不讲“完成标准”
Maintainer/Lead 规则制定、门禁维护、发布决策 规则有文档但没人执行

三、协作的最小闭环

一个需求从提出到上线，至少要经过：

需求澄清 -> Issue -> 分支开发 -> PR -> Review + CI -> 合并 -> 发布 -> 复盘

关键点：

  • 没有 Issue 的 PR，后续很难追责和复盘。
  • 没有测试证据的合并，风险会后移到线上。
  • 没有 Tag 的发布，回滚成本高。

四、常见反模式与修复动作

  1. 直推 main

    • 风险：绕过审查与门禁。
    • 修复：开启分支保护，禁用 direct push。

  2. 大 PR 一次塞完

    • 风险：Review 质量下降，合并冲突上升。
    • 修复：按子问题拆成小 PR，1 个 PR 只做 1~2 件事。

  3. Review 只看“能不能跑”

    • 风险：隐藏逻辑回归。
    • 修复：引入 review checklist（行为、边界、测试、可回滚）。

  4. 上线后才发现没法回滚

    • 风险：故障恢复慢。
    • 修复：每次发布强制 tag + release note。

五、本书后续路径

  • 第2~3章：建立标准工作流（分支、PR、Review）。
  • 第4章：把需求分析沉淀成可执行 Issue。
  • 第5~6章：实战复杂项目与开源协作。
  • 第7章：引入 GitHub Copilot 人机协作。
  • 第8~10章：质量、发布、模板化落地。

团队效率不是靠“更努力”，而是靠“协作流程可复制”。