6.3 GitHub - 维护项目

有人对你的代码进行了更改并向你发送了拉取请求。你应该会收到一封关于新拉取请求的通知邮件，它应该看起来像新拉取请求的邮件通知。

这封邮件有几点值得注意。它会给你一个简短的 diffstat——一个列出在拉取请求中更改了哪些文件以及更改了多少的列表。它还提供了指向 GitHub 上该拉取请求的链接。此外，它还提供了几个可以在命令行使用的 URL。

如果你注意到那行写着git pull <url> patch-1的命令，这是一种无需添加远程仓库即可合并远程分支的简单方法。我们之前在检出远程分支中简要介绍过这一点。如果你愿意，可以创建一个主题分支并切换到该分支，然后运行此命令来合并拉取请求的更改。

其他有趣的 URL 是.diff和.patch URL，顾名思义，它们提供了拉取请求的统一差异（unified diff）和补丁（patch）版本。理论上，你可以用类似这样的方式合并拉取请求的工作：

正如我们在GitHub 流程中所介绍的，你现在可以与打开拉取请求的人进行对话。你可以评论特定的代码行、评论整个提交，或者评论整个拉取请求本身，并且处处使用 GitHub 风味 Markdown。

每次有人评论拉取请求时，你都会继续收到邮件通知，以便你了解正在进行的活动。每封邮件都将包含指向活动发生位置的拉取请求链接，你也可以直接回复邮件以评论拉取请求的讨论串。

一旦代码达到你喜欢的状态并希望将其合并，你可以通过我们之前看到的git pull <url> <branch>语法在本地拉取代码并合并，或者通过将派生仓库添加为远程仓库然后拉取（fetch）并合并。

如果合并很简单，你也可以直接点击 GitHub 网站上的“合并”按钮。这将执行一次“非快进合并”，即使可以进行快进合并，也会创建一个合并提交。这意味着无论如何，每次你点击合并按钮，都会创建一个合并提交。如合并按钮和手动合并拉取请求的说明所示，如果你点击提示链接，GitHub 会提供所有这些信息。

如果你决定不合并它，你也可以直接关闭拉取请求，打开它的人会收到通知。

如果你正在处理大量拉取请求，并且不想每次都添加一堆远程仓库或进行一次性拉取，GitHub 允许你使用一个巧妙的技巧。这有点高级，我们将在Refspec中更详细地介绍它，但它可能非常有用。

GitHub 实际上将仓库的拉取请求分支作为服务器上的伪分支进行宣传。默认情况下，当你克隆时不会获取它们，但它们以一种隐蔽的方式存在，并且你可以相当容易地访问它们。

为了演示这一点，我们将使用一个低级命令（通常被称为“底层命令”，我们将在底层命令与日常命令中阅读更多相关内容），名为ls-remote。这个命令通常不用于日常 Git 操作，但它有助于向我们展示服务器上存在哪些引用。

如果我们将此命令作用于我们之前使用的“blink”仓库，我们将获得仓库中所有分支、标签和其他引用的列表。

当然，如果你在自己的仓库中运行git ls-remote origin或任何你想检查的远程仓库，它将向你显示类似的内容。

如果仓库在 GitHub 上，并且你打开了任何拉取请求，你将获得以refs/pull/为前缀的这些引用。这些基本上是分支，但由于它们不在refs/heads/下，所以当你从服务器克隆或拉取（fetch）时通常不会获取它们——拉取过程通常会忽略它们。

每个拉取请求有两个引用——其中以/head结尾的引用指向的提交与拉取请求分支中的最新提交完全相同。因此，如果有人在我们的仓库中打开一个拉取请求，他们的分支名为bug-fix并指向提交a5a775，那么在我们的仓库中，我们将不会有一个bug-fix分支（因为那在他们的派生仓库中），但我们会有一个指向a5a775的pull/<pr#>/head引用。这意味着我们可以很容易地一次性拉取所有拉取请求分支，而无需添加一堆远程仓库。

现在，你可以直接获取引用。

这告诉 Git：“连接到origin远程仓库，并下载名为refs/pull/958/head的引用。” Git 会愉快地遵从，下载构建该引用所需的所有内容，并将指向你想要提交的指针放在.git/FETCH_HEAD下。你可以接着将其git merge FETCH_HEAD合并到你想测试的分支中，但这样做的合并提交消息看起来会有点奇怪。此外，如果你正在审查大量拉取请求，这会变得很繁琐。

还有一种方法可以获取所有拉取请求，并在你连接到远程仓库时保持它们最新。在你喜欢的编辑器中打开.git/config，然后找到origin远程仓库。它应该看起来像这样：

那行以fetch =开头的行是一个“引用规范”（refspec）。它是一种将远程仓库中的名称与本地.git目录中的名称进行映射的方式。这条特定的规则告诉 Git：“远程仓库中refs/heads下的内容应该进入我本地仓库的refs/remotes/origin下。” 你可以修改此部分以添加另一个引用规范：

最后一行告诉 Git：“所有看起来像refs/pull/123/head的引用都应该在本地存储为refs/remotes/origin/pr/123。”现在，如果你保存该文件，并执行git fetch：

现在，所有远程拉取请求都在本地由引用表示，这些引用就像跟踪分支一样；它们是只读的，并且在你执行拉取（fetch）时更新。这使得在本地尝试拉取请求的代码变得超级容易。

眼尖的你可能会注意到引用规范的远程部分末尾的head。在 GitHub 端还有一个refs/pull/#/merge引用，它代表了如果你在网站上点击“合并”按钮后将产生的提交。这可以让你在点击按钮之前就测试合并。

你不仅可以打开以 main 或master分支为目标的拉取请求，实际上你还可以打开以网络中任何分支为目标的拉取请求。事实上，你甚至可以以另一个拉取请求为目标。

如果你看到一个拉取请求正朝着正确的方向发展，并且你有一个依赖于它的更改想法，或者你不确定这个想法是否好，或者你只是没有目标分支的推送权限，你可以直接向它打开一个拉取请求。

当你去打开一个拉取请求时，页面顶部有一个框，指定了你请求拉取到哪个分支以及从哪个分支拉取。如果你点击该框右侧的“编辑”按钮，你不仅可以更改分支，还可以更改是哪个派生仓库。

在这里，你可以相当容易地指定将你的新分支合并到另一个拉取请求或项目的另一个派生仓库中。

当我们在这里提及 GitHub 的“通知”时，我们指的是 GitHub 在事件发生时与你联系的特定方式，并且有几种不同的方式可以配置它们。如果你从设置页面进入“通知中心”选项卡，你可以看到一些可用的选项。

两种选择是通过“电子邮件”和“网页”接收通知，你可以选择两者之一、两者皆无或两者兼有，用于你积极参与的活动以及你关注的仓库的活动。

如果你使用“master”以外的分支作为你的默认分支，希望人们默认在该分支上打开拉取请求或看到它，你可以在仓库设置页面的“选项”选项卡下更改它。

只需在下拉列表中更改默认分支，此后它将成为所有主要操作的默认设置，包括当有人克隆仓库时默认检出的分支。

如果你想将项目转移到 GitHub 中的另一个用户或组织，在你的仓库设置页面相同的“选项”选项卡底部有一个“转移所有权”选项，允许你执行此操作。

如果你放弃了一个项目并且有人想接管它，或者如果你的项目变得越来越大并希望将其移到一个组织中，这将很有帮助。

这不仅会将仓库及其所有关注者和星标移动到另一个位置，还会设置从你的 URL 到新位置的重定向。它还会重定向 Git 的克隆（clones）和拉取（fetches），而不仅仅是网页请求。