Pull Request 不是拉取代码，而是请求检查并合并
一句话先说清楚
Pull Request，常缩写为 PR，是你在 GitHub 上发出的一份合并申请：
请检查
fix-homepage-typo分支和main的差别；如果没有问题，请把这些变化合并进main。
它不是一段代码，也不是 git pull 命令。它是围绕一组代码变化建立的讨论和检查页面。
什么时候使用 PR
- 你在团队项目中完成一个功能，想让同事检查。
- 你修改开源项目，想请维护者接收。
- 你独立工作，但想在合并前集中检查 diff 和自动测试。
- 部署规则要求只有合并到 main 才能上线。
发 PR 以前必须有什么
假设你已经完成：
text
本地分支：fix-homepage-typo
修改内容：首页错别字
本地验证：页面可以正常打开
Commit：修正首页标题错别字
Push：分支已经上传 GitHub如果分支还只在电脑上，GitHub 看不到它，也无法比较和创建 PR。
在 GitHub 创建 PR 的完整操作
方法一：使用提示按钮
Push 新分支后打开 GitHub，页面通常显示 Compare & pull request。点击它。
方法二：手动创建
- 打开仓库的
Pull requests标签。 - 点击
New pull request。 - 设置
base: main。 - 设置
compare: fix-homepage-typo。 - 先查看
Files changed，确认只有预期变化。 - 点击
Create pull request。
Base 和 Compare 到底怎么看
text
base: main意思是：修改最后准备进入哪里。
text
compare: fix-homepage-typo意思是：拿哪条分支的变化来申请。
如果选反，页面可能显示大量奇怪变化。不要直接提交，先重新选择。
标题和说明具体写什么
不清楚的标题：
text
Update files一眼能懂的标题：
text
修正首页标题中的错别字说明可以照这个结构写：
text
做了什么
- 把首页“我的笔计”改成“我的笔记”
为什么修改
- 当前标题有错别字
怎样验证
- 运行 npm run dev
- 打开首页确认标题正确PR 页面上的东西分别是什么
Conversation
说明、讨论和审核意见所在的位置。
Commits
这次 PR 包含哪些版本存档。
Checks
自动构建、测试、代码规范检查。绿色通常表示通过，红色表示至少有一项失败。
Files changed
最终要进入 base 分支的逐行变化。合并前一定看这里。
Review
别人可以批准、留言，或者要求修改。
别人要求修改以后怎么办
不需要关闭 PR，也不需要重新建一个 PR。
继续在同一条本地分支修改：
bash
git switch fix-homepage-typo
git status
git diff
git add docs/index.md
git commit -m "根据审核意见调整标题"
git pushPush 完成后，原来的 PR 会自动出现新 commit 和最新 diff。
Merge 发生了什么
检查通过后，拥有权限的人点击 Merge。此时分支中的修改正式进入 base 分支。
text
PR 打开 只是提出申请
Review 检查和讨论
Merge 接受变化进入 main
Deploy 是否上线还要看项目部署规则PR、Issue、Commit 和 Merge 不要混
Issue
记录问题或需求，例如“首页有一个错别字”。它可以还没有代码。
Commit
一个有说明的代码版本，存在于分支上。
Pull Request
把一条分支的变化拿出来讨论、检查并申请合并。
Merge
真正把变化接入目标分支的动作。
常见失败
GitHub 说没有可以比较的变化
可能是分支没有新 commit、没有 push，或者 base 和 compare 选成同一条分支。
Merge 按钮是灰色
可能还在等待自动检查、需要审核批准、存在冲突，或者你没有合并权限。
PR 合并了但本地 main 还是旧的
合并发生在 GitHub。回到电脑运行：
bash
git switch main
git pull --ff-onlyPR 已经打开，但维护者要求你再改一处。应该关掉 PR 重来吗？
答案：通常不用。回到同一条分支继续修改、commit 和 push，原 PR 会自动更新。