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

Question

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

这是场景:我有一个 GitHub 存储库(称之为“A”)。如果有人想要进行更新，他们会将该存储库 fork 到他们自己的存储库中(称为“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 到 GitHub 的远程存储库 A 的 A )，存储库可能如下所示:

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

master和 document_more_things存储库中存在分支A ，无需 fork 存储库B ，作者可以从 A/document_more_things 发起拉取请求至A/master .当拉取请求被接受时，历史将如下所示，带有 g合并提交:

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

是否document_more_things在 A或 B实际上并不重要，因为 Git 只关心提交及其祖先。如果 B在提交 C 时 fork 和 d e f制作于 B/master ，我们将在来自 B/master 的拉取请求后得到相同的图片至A/master就像我们从 A/document_more_things 做的那样.

如果你想更好地了解 Git 的模型，有很多在线资源可以推荐:

Try Git是一个很酷的交互式教程，通过基本命令

Learn Git Branching类似，在您执行操作时可以很好地可视化存储库状态

Pro Git几乎是关于使用 Git 的规范文本(除了 actual documentation )，并且有一个关于 the basics 的好章节

GitHub 有一个可靠的列表 good resources