协作——Pull Request 与代码评审
在团队里，没人直接往 main 上。开 → → 开 → 评审 → 。所有软件团队都靠这套流程运转。
学习目标
- 能走通开分支 → PR → 评审 → 合并这条流程
- 能写出让人好评审的 Pull Request
- 知道给别人项目做贡献的 流程
在团队里不会直接往 main 上提交。开一条分支干活，推到，然后开一个 Pull Request（PR），请求把这些改动合进去。评审的人看过、留下意见，通过之后才合并。 和 GitLab 都是这套流程，你今后进的公司基本也一样。
PR 不是把交上去挨检查的地方，而是同步意图的地方。标题写清做了什么，正文写清为什么需要、怎么验证的，评审就会快得多。而且 PR 越小越好：超过三百行左右，评审的人就很难看细，往往直接点通过。
收到评审意见后，在同一条分支上再提交、再推送，PR 会自动更新。要给别人的公开做贡献，先把它 fork 到自己账号下，在自己的 fork 里开分支，然后向原仓库发 PR。用 gh 命令（GitHub ），不出就能创建、查看和签出 PR。
轻松理解
Pull Request 就像把作业贴到教室墙上之前，先交上去让人检查。队友们阅读改动、留下意见，只有获得批准之后，才会合并进 main。
本步骤要掌握的命令
别光用眼睛看，去终端里真敲一遍。手记住了，工作时才使得出来。
git switch -c fix/session-expiry- 为这次工作开一条分支，名字要能看出在干什么。
git push -u origin fix/session-expiry- 把分支推到远程，这样才能基于它开 PR。
gh pr create --fill- 在终端里创建 PR，标题和正文用提交内容自动填好。
gh pr checkout <number>- 把别人的 PR 拉到本地跑一遍，再决定是否通过。
常见错误和改正方法
开了一个塞满互不相关改动的超大 Pull Request。评审的人没法好好读，错误就溜过去了。一个 Pull Request 只放一个目的；改动变大时，就拆成几条更小的分支。
这一栏由你自己标记，这里不打分。
要把这一阶段标记为已理解吗？
目前还不能取消，请在真正理解后再标记。
已标记为理解
这一栏由你自己标记，这里不打分。