第一次给GitHub开源项目提PR：从Fork到合并的避坑流程
先别急着点“Edit”：贡献前3分钟检查 ⭐
“哥，我就改个错别字，也要这么麻烦？”要的，孩子。互联网老登见过太多新人把主分支改成一锅粥，最后含泪删库重来。本文按GitHub PR流程教程走一遍，适合第一次参与开源项目、科研代码仓库或文档修订的人。
Q：我该先看什么？先看仓库里的 README、CONTRIBUTING、LICENSE、Issues。没有 CONTRIBUTING 也别慌，按通用流程来。重点确认：项目是否接受PR、代码风格、测试命令、分支命名规则。
老司机提示：我实测过，一个40MB左右的文档型仓库，从Fork到发出小PR，熟练后约8分钟；第一次通常30分钟，卡点多半不是代码，是Git身份和分支。
Fork、分支、提交：照抄这套命令 ⭐⭐
Q：GitHub fork怎么用？点击仓库右上角 Fork，把项目复制到自己账号下。然后本地克隆你的Fork，而不是原仓库：
git clone [email protected]:你的用户名/项目名.git
cd 项目名
git remote add upstream [email protected]:原作者/项目名.git
git remote -v
Q：为什么要建分支？因为 main/master 是地基，别在地基上蹦迪。每个改动单独一个分支：
git checkout -b docs-fix-citation-typo
修改文件后，先看差异：
git diff
提交前建议运行项目测试。比如Python项目常见：
pytest
ruff check .
然后提交：
git add README.md
git commit -m "docs: fix citation typo in README"
git push origin docs-fix-citation-typo
Q：Commit信息怎么写？推荐“类型: 做了什么”，如 docs、fix、test、refactor。别写“update”“111”“改一下”，这类提交维护者看了血压会飙。
发PR、改意见、冲突急救 ⭐⭐⭐
打开GitHub页面，点 Compare & pull request。标题写清楚，描述里放三件事：改了什么、为什么改、怎么验证。例如：“修正文献引用年份；原文与DOI页面不一致；本地运行 pytest，42 passed，耗时6.3s。”这就是GitHub开源项目贡献指南里最加分的部分。
Q：PR被要求修改怎么办？别玻璃心，维护者不是针对你。按评论改完后继续在同一分支提交并 push，PR会自动更新：
git add .
git commit -m "docs: address review comments"
git push
Q：出现冲突怎么处理？这是GitHub冲突解决教程最常见场景：你的分支落后了。
git fetch upstream
git rebase upstream/main
打开冲突文件，保留正确内容，删除 <<<<<<<、=======、>>>>>>> 标记，再执行：
git add 冲突文件
git rebase --continue
git push --force-with-lease
排障树：
- push失败：先检查是否在正确分支，运行
git branch。 - PR没更新：确认 push 到的是 PR 对应分支。
- 测试失败：先本地复现，再看失败日志第一条，不要从最后一屏开始猜。
- 网络抽风：优先试GitHub官方SSH、HTTPS切换；安卓端查资料时，可用浏览器、GitHub App，网络工具如clash安卓、UU加速器或 Roxi（https://wizzegroup.com）只是可选方案，免费/官方路径能用就先用。
如何验证真的搞定：PR页面显示无冲突；CI全部绿色；Files changed只包含预期文件；本地运行测试通过；维护者没有未处理评论。还有问题就留言问，老哥慢慢带你，不笑你，谁还没当过萌新呢。