GitHub 提交 Pull Request 的完整流程

流程如下

1.首先要找到你需要提 Pull requests 的库 2.点击 Fork 将库 Fork 到自己的库中 3.修改代码提交 commit 到自己的 Fork 的库中 4.到所需提 Pull requests 的库中，点击 Pull requests 再点击 New Pull requests 5.点击如图所示 compare across forks 和 fork 中的库比较 github提pr

选择自己的库以及所需提交的库即可

命令行版的完整流程

界面点起来直观，但每次都点一遍很烦。我实际是这么做的：

# 1. clone 自己 fork 的仓库
git clone git@github.com:<你的用户名>/<repo>.git
cd <repo>

# 2. 把原仓库加成 upstream 远端，这一步是关键
git remote add upstream git@github.com:<原作者>/<repo>.git
git remote -v
# origin    → 你的 fork（有写权限）
# upstream  → 原仓库（只读）

# 3. 从 upstream 拉最新代码，保证基于最新的 main 开分支
git fetch upstream
git checkout -b fix/some-bug upstream/main

# 4. 改完提交
git add . && git commit -m "fix: 修复 xxx"

# 5. 推到自己的 fork
git push -u origin fix/some-bug

推完 GitHub 会在终端输出一个「Create a pull request」链接，直接点开就是。或者用 gh CLI 一步到位：

gh pr create --base main --head fix/some-bug \
  --title "fix: 修复 xxx" \
  --body "## 改动说明\n- ...\n\n## 测试\n- ..."

# 交互式创建（会引导你填标题和正文）
gh pr create --web

# 看自己提的 PR 状态
gh pr status
gh pr checks

gh 是 GitHub 官方 CLI，brew install gh 装完 gh auth login 认证一次，之后提 PR、看 review 意见、合并都能在终端完成。

upstream 这一步为什么重要

一定要在 upstream 的最新提交上开分支，不要在自己 fork 的 main 上开。 这是新手提 PR 最常见的问题来源。

fork 是一次性快照，你 fork 之后原仓库继续往前走，你的 fork 的 main 就停在了 fork 那一刻。如果基于这个过时的 main 开分支改代码，提出来的 PR 会包含大量「原仓库已经有了」的差异，diff 里混进几十个不属于你的提交，维护者根本没法 review。

同步 fork 的 main：

git checkout main
git fetch upstream
git merge upstream/main      # 或者 git rebase upstream/main
git push origin main

用 gh 一句话搞定：

gh repo sync <你的用户名>/<repo>

GitHub 网页上 fork 仓库的首页也有个 Sync fork 按钮，效果一样。

一个 PR 只做一件事

这条比技术细节更重要。维护者的时间有限，一个 PR 里既改 bug 又顺手格式化了 20 个文件，review 成本高得离谱，大概率就被搁置了。

所以：

一个 PR 对应一个问题。发现别的问题就另开分支另提 PR。
不要顺手跑 Prettier / ESLint 格式化整个项目。格式改动会把真实改动淹没在几千行 diff 里。项目的格式约定和你本地编辑器不一致时，先确认项目有没有 .editorconfig / .prettierrc，按项目的来。
不要提交 lock 文件的无关变化。你本地 pnpm install 可能会改动 pnpm-lock.yaml，如果这次 PR 没有增删依赖，把它 checkout 回去：git checkout upstream/main -- pnpm-lock.yaml。

提交信息和分支命名

多数活跃项目要求 Conventional Commits，格式是 <type>(<scope>): <subject>：

feat: 新功能
fix: 修 bug
docs: 只改文档
style: 只改格式，不影响逻辑
refactor: 重构，不改行为
perf: 性能优化
test: 测试相关
chore: 构建、依赖、工具链

分支名跟着走：fix/login-redirect、feat/dark-mode、docs/readme-typo。

提 PR 前先读一遍仓库根目录的 CONTRIBUTING.md。里面通常写明了 commit 规范、要不要跑测试、要不要加 changelog 条目、代码风格要求。不看这个文件直接提，被要求返工的概率很高。

PR 提交后的改动怎么处理

Review 后要改代码，不需要关掉 PR 重开。直接往同一个分支推新提交，PR 会自动更新：

git add . && git commit -m "fix: 按 review 意见调整"
git push origin fix/some-bug

如果维护者要求「压成一个提交」（squash），或者要求 rebase 到最新的 main：

# 压缩最近 3 个提交为 1 个
git rebase -i HEAD~3
# 在编辑器里把后面几行的 pick 改成 s（squash）

# rebase 到最新 upstream
git fetch upstream
git rebase upstream/main

# rebase 改写了历史，必须强推
# 用 --force-with-lease 而不是 -f，它会在远端有别人的新提交时拒绝推送
git push --force-with-lease origin fix/some-bug

--force-with-lease 比 --force 安全，它先检查远端分支是否还是你上次见到的那个状态，有变化就拒绝。协作分支上强推必须用它。

不过强推只应该发生在自己的 fork 分支上。已经有人基于你的分支工作，或者这是主仓库的共享分支，就不要强推。

常见状况

PR 显示 This branch has conflicts that must be resolved：原仓库和你改的地方撞了。在本地 rebase 到最新 main 解决冲突再强推。GitHub 网页也提供了简单冲突的在线编辑，但复杂冲突还是本地处理靠谱。

CI 挂了：点开 checks 看日志。常见的是 lint 不通过或者测试没跑。提 PR 之前本地先跑一遍 pnpm lint && pnpm test 能省掉一轮往返。

改错了 base 分支：PR 页面标题下方的 Edit 按钮可以改 base，不用重开 PR。有些项目要求提到 develop 而不是 main，这个细节 CONTRIBUTING.md 里通常有写。

想撤回 PR：点 Close pull request。分支和提交都还在，之后可以 Reopen。彻底不要了再删分支。

PR 里多了别人的提交：说明 base 选错了，或者你的分支基于一个过时的点。用 git log --oneline upstream/main..HEAD 确认这个分支到底带了哪些提交，只应该看到你自己的。多出来的就 rebase 掉。