GitHub PR 工作流

它解决的具体问题

多人协作里，PR 的风险很少只发生在 git push 那一刻。分支起点不清、提交粒度混乱、PR 描述缺上下文、CI 没看就合并，都会把问题拖到 review 或生产环境。

这个技能不替代工程判断，它把 PR 生命周期拆成可检查清单：从 branch 开始，经过 commit、open、CI，最终到 merge。

它如何工作

• branch：先确认基线与目标范围，再创建小而可验证的分支。
• commit：提交内容应能对应 PR 目的，方便 review 和回溯。
• open：PR 标题、描述和改动范围要让协作者快速理解。
• CI：关注 CI 结果，失败时先定位是环境、测试还是改动本身。
• merge：合并前确认策略、冲突、审查和发布影响。

适用边界与注意点

• 它适合 Linux、macOS、Windows 上的常规 PR 流程，但仍需仓库权限和可用 Git 环境。
• 它不会替你决定如何拆需求，也不会自动修复 CI 失败。
• CI 通过不是合并的充分条件；业务正确性仍需要 review 确认。
• 若团队使用 squash、rebase 或 merge commit，合并前先确认约定。
• 鉴权可交给 github-auth，深度审查可结合 github-code-review；本技能聚焦 PR 生命周期本身。