GitHub 使用 Fork 和 PR 进行协作的标准流程

关联原始仓库后，我们便可以更为方便地随时获取原始仓库的更新情况。 举个例子，我们 Fork 并在本地克隆了仓库，但在我们修改代码的这段时间，原始仓库的其他贡献者提交了新的内容并被维护者合并了，那我们本地的文件版本就比原始仓库旧了。如果没有 upstream 这个连接，我们将很难获取到原始仓库的最新变化；而有了 upstream，我们可以轻松地执行相关命令，让本地仓库保持最新。

如以下命令：

# 从原始仓库（upstream）获取最新数据
git fetch upstream
# 将原始仓库 main 分支的最新内容合并到你本地的 main 分支
git checkout main
git merge upstream/main

执行相关命令后，便可获取原始仓库的最新文件更新。

git fetch vs. git pull 的区别

这时候一些新手朋友或接触过 git 工具的朋友可能就会觉得，该步骤相关命令的作用和平时使用的 git pull 挺像的，都是拉取仓库的最新状况，这两者有什么区别呢？

首先 git pull 命令实际上是两个命令的结合：git fetch + git merge 或 git rebase，也就是包含两个主要动作下载 + 合并。而合并便有可能产生冲突，即如果原始仓库的更新和本地的修改在同一个文件或同一行，Git 会自动触发合并（Merge）或冲突（Conflict）。 而 git fetch 则只是单纯的下载，因此它只会将原始仓库的最新数据下载到本地 Git 仓库中，但不会自动修改你当前工作目录中的任何文件。

我们平时使用的单纯的 git pull 默认形式其实为 git pull origin main，也就是将我们自己的仓库的仓库拉取到 main 分支合并。

确保主分支为最新

一般来说，在工作流中克隆到本地后的 main 都是最新的，但为确保严谨，还是需要对主分支进行更新。

git checkout main # 将分支切换到主分支
git pull upstream main # 拉取原仓库的 main 分支，合并到我们本地 fork 仓库的 main 分支

创建新分支

按协作规范，我们一般不会直接在 main 分支上对项目进行修改，而是使用命令新建一个自己的分支。

git checkout -b your-contribution-name # checkout -b 可创建新分支并直接切换至该新创建的分支
git branch # 该命令用于查看当前的分支情况

我这边创建的新分支名为 ckys-add，绿色字体和左边的星号代表目前我正处于 ckys-add 分支。

正式添加/修改文件并 push

现在我们已成功配置了仓库的信息并创建了一个新分支，因此算是做完了所有的准备工作。接下来便是正式对仓库的文件进行修改。

添加/修改文件

在该步骤中你可以将自己的代码添加进仓库，或是修改项目中的代码，进行任何你想要的增删查改。 在本示例中，我只是简单地将一些新的文件添加到了该仓库中。

我这边将图中的相关文件添加进了相关目录。

add/commit

对项目的修改进行完毕后便是我们最熟悉的 add+commit+push 三板斧了。这里稍微值得注意的是，在标准的多人协作中，commit 的信息一般需要遵守相应的格式，如 conventional commit 规范。对于 conventional commit 规范我在这里并不详细说明，读者可自行在访问官网 Coventional Commit，或是社区搜索各个大佬分享的博客。

push

现在我们需要推送分支到我们的 GitHub 仓库 (origin)，即我们 fork 出来的那个仓库，即执行以下命令：

git push origin ckys-add

对于该命令有两个选项：

1. 关于 origin： 为什么是 origin 而不是之前创建的 upstream？ origin 和 upstream 它们被称为远程别名 (Remote Names)，或简称远程 (Remotes)，可简单理解为仓库的一个别名，即一个 origin 就映射一个你拥有的仓库，而 upstream 便映射的是原仓库。这下便可以理解了，我们不是原仓库的协作者，是没有原仓库的相关权限的，因此自然不可能 git push upstream。
2. 关于 ckys-add： 这里的 ckys-add 是明确指定推送哪个本地分支，必须要加用于上游追踪。当然也有利用 -u 选项（git push -u origin ckys-add）使得后续不用加以方便操作的选择，这里不过多赘述。

创建 PR 并提交

返回网页端

现在我们返回 github 网页，进入我们的 fork 仓库，可以看到这里仓库名称下方出现了比较 & 拉取请求按钮，说明仓库已经检测到了我们通过 ckys-add 分支 push 了新的推送，可以进行拉取请求（pull request）操作了。

确认 PR 目标、来源等信息

点击比较 & 拉取请求按钮后，我们会看到如下页面，在该页面的顶部会出现四个重要信息，这里我在图中已经框中并标号了，分别为基础仓库（base repository）、基础分支（base branch）、头部仓库（head repository）、比较分支（compare branch）。

对四个配置信息进行简单解释：

通过这四个信息我们可以完成最终的 PR 提交确认。

填写 PR 描述

在上张图片的中间，我们可以看到添加标题和添加描述的按钮填写框，在这里我们需要详细说明我们修改的功能改动和实现思路，同时严格的话还需要 @ 项目评审，等待评审人员的 review 和留言。

提交 PR

确认无误后，点击绿色的 创建拉取请求 (Create pull request) 按钮，提交成功。

提交结束及后续

在提交成功后，页面上方的菜单栏中有四个功能可供我们查看，分别为讨论（Conversation）、提交（Commits）、检查（Checks）、更改的文件（Files changed）。

'Conversation' (讨论) 标签页

该页面是第一个主视图，也就上图所展示的，用于沟通和状态概览。

• 评审意见和评论：我们 @维护者 的所有评论、疑问或建议都会在这里显示。
• LGTM/批准状态：维护者点击'Approve'或留下 LGTM 的行为会在这里记录。
• 事件时间线：底部的时间线记录了 PR 的创建、提交更新和最终合并/关闭等关键动作。

'Commits' (提交) 标签页

这里按时间顺序显示我们在这个分支（我这里是 ckys-add 分支）上做的所有 git commit 记录。

'Checks' (检查) 标签页

这里在规范的仓库中一般会有自动化检查成果 (CI/CD)，所有的自动化测试、格式检查等流水线的结果会在这里显示。

• 绿色勾 ✓ (Success): 表示自动化检查通过。
• 红色叉 × (Failure): 表示有检查失败，需要点击'Details'查看日志并修复问题。
• 但我这里状态信息显示 workflow runs completed with no jobs (工作流运行完成，但没有作业)，表明我这个特定的开源项目 (HDU-Course/HDU-FinalExamPaper) 是没有使用 GitHub Actions 或其他 CI/CD 工具来运行自动化测试或代码检查。

'Files changed' (文件更改) 标签页

该页面用于显示我们提交的文件与目标分支之间的所有差异。 评审者通常会在这里对文件的特定行进行评论（即 Thread/会话）。当我们处理完一个意见后，我们会回到'Conversation'标签页点击'Resolve conversation'关闭它。