Docs Library
发起第一个 Pull Request
从分支提交过渡到协作评审：整理改动范围、补齐说明信息、发起第一个可评审且可合并的 Pull Request。
- 刚开始系统学 Git 的新手
- 想补齐最小协作闭环的人
- 会打开终端并进入仓库目录
- 知道本地和远端仓库的基本区别
- 跳过顺序直接学高风险命令
- 把示例命令直接用到当前工作仓库
引用与延伸阅读
- About pull requests [讨论]
- Git push [官方]
学完这篇你会掌握什么
- 准备好发起 PR 前的最小检查清单
- 在本地完成 rebase 同步后再推送分支
- 写清楚 PR 的改动目的、变更点和验证方式
- 理解 PR 是协作接口，不只是代码上传入口
先想一个问题
你已经在一个功能分支上完成了开发，也做了提交。现在你想把改动"交给团队"。但如果你只是 push 分支然后在 GitHub 上点了一下 New Pull Request，reviewer 点开一看——没有描述、没有上下文、提交信息是"fix"和"update"——你觉得他能理解你要做什么吗？
PR 不是代码上传入口，而是你写给 reviewer 的一封信。
发起前的最小检查清单
在 push 之前，先检查：
- 改动是否只围绕一件事——如果一个 PR 同时修了 bug、加了功能、还格式化了代码，reviewer 很难一次性 Review
- 分支是否同步过最新主线——用
git fetch origin && git rebase origin/main确保分支基于最新主线 - 提交信息是否可读——
git log --oneline看过去几条提交，自己能不能看懂
这三条都满足，就可以准备发起 PR 了。
最小流程
git fetch origin
git rebase origin/main
git push -u origin feature/first-pr
然后在平台创建 PR，补齐三要素：
- 改动目的：为什么改这个？要解决什么问题？
- 核心变更点：改了哪些文件、改了什么逻辑？
- 风险与验证方式：怎么确认改对了？有没有需要特别注意的副作用？
一个好的 PR 描述可以让 review 周期从"反复追问"缩短到"一次性通过"。
为什么 PR 描述比你想的更重要
Reviewer 在看你的代码之前，先看到的是你的 PR 描述。如果描述说清楚了"为什么改"和"怎么验证"，reviewer 就能带着上下文看代码——而不是反过来，先猜你要做什么，再看代码对不对。
一个写得太简略的 PR，本质上是把理解成本转嫁给了 reviewer。
PR 是协作接口，不只是代码上传入口。描述不完整会显著增加评审往返成本。
给你的练习
- 在测试仓库中创建一个功能分支，做 2-3 个提交，用 git rebase -i 整理成 1 个干净提交后发起 PR
- 故意写一个没有描述的 PR，找同事 review，记录他问了多少个问题
- 下次写 PR 时，先写描述再写代码——看 review 效率是否提升
接下来建议继续学什么
handle review feedback— 如何处理 review 反馈pull request prep— PR 提交前的准备清单pull requests and reviews— PR 与代码审查最佳实践
延伸阅读
沿着同一主题继续深入：