拉取请求在 GitHub Desktop 中究竟做了什么

Question

如果这太基本或重复，我很抱歉，但我在这里感到困惑。我在 GitHub 帮助中找不到答案（我确实看过）并且我确实问过一些软件开发人员（我使用 GitHub 来存储文档），但他们也不知道！

场景如下：我有一个 GitHub 存储库（称为“A”）。如果有人想要进行更新，他们会将该存储库分叉到他们自己的存储库中（称为“B”）。然后，他们可以单击“在桌面中克隆”以获取本地副本。

他们在本地进行编辑，然后打开 GitHub Desktop。

在 GitHub Desktop 中，他们可以使用“Commit to Master”，然后点击“Sync”按钮。这会将它们与存储库 B 同步。如果他们想将编辑内容复制到存储库 A，他们会进入 GitHub 并发出拉取请求。我明白了。

但是 GitHub Desktop 也有一个“拉取请求”按钮，我不明白它向谁提出请求！它是存储库 A 还是存储库 B？或者完全不同的东西？

如果是仓库 B，那么提交/同步和拉取请求按钮有什么区别？

我无法尝试，因为那个按钮对我来说总是灰色的（也许是因为我拥有存储库？）

用户是否可以直接从 GitHub Desktop 向存储库 A 发出拉取请求 - 还是通过存储库 B 始终是一个两步过程？

Answer 1

如果您开始考虑分支而不是存储库，拉取请求的行为将更加清晰。一个存储库可能包含许多分支，当您创建拉取请求时，您可以选择要将哪个分支合并到哪个其他分支中。

就您而言，到目前为止，听起来有两个有趣的分支：

• A/master
• B/master

也就是说，存储库A和B每个都有一个master分支。当您看到从存储B库打开到存储库的拉取请求时A，实际上它是从一个分支打开B/master到另一个分支A/master。

知道这一点，实际上您可以在具有共同提交历史记录的任何分支之间打开拉取请求。例如，如果有人创建了一个A/document_more_things分支并进行了一些提交（和同步，用 Git 的话说就是push从他们的本地存储库A到 GitHub 的远程存储库A），存储库可能如下所示：

a - b - c            # master
         \
          d - e - f  # document_more_things

无论是master和document_more_things在存储库分支存在A，而不需要分出的代码库中B，笔者可以打开一个pull请求A/document_more_things来A/master。当拉取请求被接受时，历史将如下所示，并带有一个g 合并提交：

a - b - c --------- g  # master
         \         /
          d - e - f

无论document_more_things是在A或B实际上无所谓非常多，因为混帐只在乎提交和他们的祖先。如果B在提交时分叉C并d e f创建B/master，我们将在从B/masterto拉取请求后得到与A/master从A/document_more_things.

如果你想更好地理解 Git 的模型，网上有很多资源可以推荐：

• Try Git是一个很酷的交互式教程，通过基本命令
• Learn Git Branching与此类似，在您执行操作时可以很好地可视化存储库状态
• Pro Git几乎是关于使用 Git 的规范文本（除了实际文档），并且有一个关于基础知识的好章节
• GitHub 有一个很好的资源列表