前两节你已经掌握了 Git 进阶操作（0003）和 GitHub Actions CI/CD（0006）。这节课填上中间缺失的一环：GitHub 作为协作平台——如何管理任务、发起和审查代码变更、用规则保护代码质量。
这些是 DevOps 日常的高频操作：配置分支保护让 CI 通过才能合并、Review 别人的 Terraform/Ansible 代码、管理团队的技术债务清单。
Issue 是 GitHub 项目管理的核心单元。它远不止「报告 bug」——成熟的团队用它来做 任务管理、技术讨论、功能设计、会议记录。
| 属性 | 用途 | DevOps 场景 |
|---|---|---|
| Labels（标签） | 分类和优先级 | bug / enhancement / infra / security / priority-high |
| Milestones（里程碑） | 按版本/迭代分组 | 「v1.2.0」「Q3 Sprint 3」「安全加固」 |
| Assignees（负责人） | 谁在干这个活 | 分配 Terraform 模块开发任务 |
| Projects（项目看板） | Kanban 视图 | Todo → In Progress → Review → Done |
在 .github/ISSUE_TEMPLATE/ 下放 YAML 文件，创建 Issue 时自动显示模板选择器：
# .github/ISSUE_TEMPLATE/bug_report.yml
name: Bug Report
description: 报告一个 bug
labels: [bug, triage]
body:
- type: textarea
attributes:
label: 发生了什么？
description: 清晰描述你遇到的问题
validations:
required: true
- type: textarea
attributes:
label: 复现步骤
description: 1. 执行... 2. 点击... 3. 看到...
- type: input
attributes:
label: 版本号
placeholder: v1.2.3在 PR 描述里写 Closes #42 或 Fixes #42——PR 合并后，Issue #42 自动关闭。这是 GitHub 最核心的「代码变更 → 任务完成」自动化。
PR 不只是「请求合并代码」。它是一个讨论线程 + 代码 diff + CI 检查结果 + 审批状态的综合视图。
创建分支 → 写代码 → git push → 开 PR（Draft）
│
Mark as ready ←── 继续改 ──←── CI 失败？
│
请求 Review ──→ Reviewer 提意见 ──→ 修改 → 再 push（PR 自动更新）
│
全部通过 → Approve → Merge（Squash / Rebase / Merge commit）开 PR 时点「Create draft pull request」——别人能看到代码但不能 merge，适合「先给大家看看方向对不对」的早期反馈。
Review 代码时，点行号旁边的 +/- 按钮，写建议代码——PR 作者可以一键接受。这是 GitHub 最高效的 Review 交互：
```suggestion
# 你的建议代码
echo "Deploying to $ENVIRONMENT" # Reviewer 建议加上环境变量提示
```| 策略 | 结果 | 什么时候用 |
|---|---|---|
| Merge commit | 创建一个 merge commit，保留完整分支历史 | 多人协作的长分支 |
| Squash and merge | 所有 commit 压缩成一个，干净整洁 | 单个 feature 的多个 WIP commit（推荐） |
| Rebase and merge | 逐个 rebase 到 main，线性历史无 merge commit | 追求完全线性历史（需配合 branch protection） |
这是 DevOps 工程师的核心职责之一：配置规则让代码质量不靠自觉、靠机械执行。
在仓库 Settings → Branches → Add rule，输入 main（或 release/* 等 pattern）：
| 规则 | 效果 | DevOps 意义 |
|---|---|---|
| Require a pull request before merging | 不能直接 push 到 main，必须走 PR | 强制 code review |
| Require approvals | 至少 N 个人点 Approve 才能 merge | 防止单人绕过审查 |
| Require status checks to pass | CI（lint/test/build）不过不允许 merge | 这就是 CI/CD 门禁！ |
| Require conversation resolution | 所有 Review 讨论必须 resolve | 确保每条意见都有回应 |
| Require linear history | 禁止 merge commit，只允许 rebase/squash | 保持 main 分支历史是一条直线 |
| Do not allow bypassing | 即使 admin 也不能跳过规则 | 防止「我就改一行，直接 push 吧」 |
在 .github/CODEOWNERS 文件里定义「谁拥有哪些代码的审查权」：
# 所有 .tf 文件的变更自动请 infra 团队 review
*.tf @myorg/infra-team
# CI/CD 配置的变更自动请 DevOps 负责人 review
.github/workflows/ @bram35mm
.github/workflows/deploy.yml @bram35mm
# 文档谁都可以改，不需要 owner
docs/效果：有人改 .tf 文件开 PR → @myorg/infra-team 自动被设为 reviewer。结合 branch protection 的「require review from code owners」，连审批都自动化了。
目标：在你的一个 GitHub 仓库上配置完整的协作流程。
# 1. 创建 Issue 模板
mkdir -p .github/ISSUE_TEMPLATE
cat > .github/ISSUE_TEMPLATE/bug_report.yml << 'EOF'
name: Bug Report
description: 报告一个问题
labels: [bug]
body:
- type: textarea
attributes:
label: 描述
validations:
required: true
- type: input
attributes:
label: 环境
placeholder: "Ubuntu 22.04, Docker 29.x"
EOF
# 2. 设置 Branch Protection（在 GitHub Web UI 上操作）
# Settings → Branches → Add rule → 输入 "main"
# 勾选：
# ☑ Require a pull request before merging
# ☑ Require approvals (设为 1)
# ☑ Require status checks to pass (搜你的 CI job 名)
# → Create
# 3. 模拟一次协作流程
git checkout -b fix/update-readme
echo "Updated at $(date)" >> README.md
git add README.md
git commit -m "docs: update README"
git push origin fix/update-readme
# → 去 GitHub 开 PR
# → 观察：你能直接 push 到 main 吗？（不能——branch protection）
# → 合并 PR（如果 CI 配了 status check，观察它是否必须通过）协作流程跑通了，但代码怎么变成「一个版本」？下一课——版本发布管理：SemVer、Tags、Releases、Changelog（0024），你将学会用语义化版本号标记每一次发布，让 CI/CD 流水线自动构建和发布。