EP06. “GitHub 协作：Fork、Pull Request、Code Review 与 Issues”

首页 › PC 工具 › Developer Tools · Git & GitHub · EP06

约 9 分钟· #EP06#Git & GitHub

团队协作的标准做法不是大家直接往 main 推，而是开分支 → 发 Pull Request → 有人审过 → 才合并
自己有仓库写入权限：直接开分支发 PR；没有权限（例如想帮开源项目改错字）：先 Fork 一份到自己账号再发 PR
Issues 是仓库自带的问题清单，报 bug、提需求、记待办都可以，PR 里写 Closes #12 合并时会自动关掉对应 Issue
一个人做项目也值得用 PR：合并前在网页上再看一次改动，常常就能抓到漏掉的错

重点内容

两种协作模式

	共享仓库模式	Fork 模式
适合	公司团队、有写入权限的协作者	开源项目、没有写入权限的外人
分支开在哪里	同一个仓库	你自己 Fork 出来的仓库
第一步	`git clone` 原仓库	在 GitHub 按 Fork，再 clone 自己那一份
PR 方向	功能分支 → `main`	你的 Fork → 原仓库

共享仓库模式：从分支到合并

flowchart TD
    A["git switch -c fix/footer-phone"] --> B["改文件、commit"]
    B --> C["git push -u origin fix/footer-phone"]
    C --> D["GitHub 上开 Pull Request"]
    D --> E["同事 Review：留言 / Approve"]
    E -->|要修改| B
    E -->|通过| F["Merge pull request"]
    F --> G["删除分支，本地 git pull"]

开 Pull Request 的步骤：

分支 push 上去后，GitHub 仓库页面会出现黄色提示条，按 Compare & pull request（或到 Pull requests 分页 → New pull request）
确认上方的方向：base: main ← compare: fix/footer-phone
写标题和说明：改了什么、为什么改、怎么测试；有对应 Issue 就写 Closes #12
右侧 Reviewers 选要审的同事
按 Create pull request；还没做完、只想先给人看，可以选 Create draft pull request

Code Review：审别人的 PR

进 PR 的 Files changed 分页，看逐行差异
鼠标移到某一行，按左边的 + 就能对那一行留言
看完按 Review changes，三个选项：

选项	意思
Comment	只是留言，不表态
Approve	同意合并
Request changes	要求修改后才能合并

作者只要在同一条分支继续 commit、push，PR 会自动更新，不用重开

合并 PR 的三种方式

按 Merge pull request 旁边的下拉箭头可以选：

方式	结果	适合
Create a merge commit	保留分支所有 commit，加一个合并 commit	想保留完整过程
Squash and merge	分支所有 commit 压成一个 commit 再合并	分支里有很多「修错字」小 commit，想让 `main` 历史干净
Rebase and merge	把 commit 一个个接在 `main` 后面，不产生合并 commit	想要一条直线的历史

合并后按 Delete branch 删掉远端分支，本地再：

git switch main
git pull
git branch -d fix/footer-phone

Fork 模式：帮别人的项目改东西

在原仓库页面右上角按 Fork → Create fork，你的账号下就多一份
git clone 你自己那份，开分支、改、commit、push
回到你 Fork 的仓库页面，按 Contribute → Open pull request，方向会是「你的 Fork → 原仓库」
等原作者审核、合并

想让自己的 Fork 跟上原仓库最新进度：在你 Fork 的页面按 Sync fork。

Issues：问题追踪

仓库的 Issues 分页 → New issue，写标题、描述、截图
右边可以设 Assignees（负责人）、Labels（例如 bug、enhancement）
每个 Issue 有编号，例如 #12，在任何留言、commit 说明里打 #12 都会变成链接

在 PR 说明里写	合并后
`Closes #12` / `Fixes #12` / `Resolves #12`	Issue #12 自动关闭
`#12`（没有关键字）	只是链接，不会关闭

⚠️ 自动关闭只在 PR 合并进默认分支（通常是 main）时生效。

保护 main 分支

仓库 Settings → Branches（或 Rules → Rulesets）可以设定规则，例如：

不能直接 push 到 main，一定要经过 PR
PR 至少要 1 个人 Approve 才能合并

团队项目建议一开始就设好，避免有人不小心直接推坏主线。

学完你会

✅ 用分支 + Pull Request 的流程协作
✅ 在 PR 上做 Code Review（留言、Approve、Request changes）
✅ 分得清三种合并方式
✅ Fork 别人的项目并发 PR
✅ 用 Issues 追踪问题，用 Closes #编号 自动关闭

常见错误

❌ Fork 之后 clone 了原仓库：你没有原仓库的写入权限，push 会失败，要 clone 自己 Fork 的那份。
❌ PR 方向选反：base 应该是要接收改动的分支（通常是 main）。
❌ Review 要求修改后重开一个新 PR：直接在同一条分支继续 push，PR 会自动更新。
❌ 一个 PR 塞了十件事：很难审，出问题也很难回退，一个 PR 只做一件事。
❌ 写 #12 以为会自动关 Issue：要加 Closes、Fixes 这类关键字。

Sources

官方文档：

📝 测验一下共 7 题