道歉，如果这是太基础，或重复，但我在这里感到困惑。我无法在GitHub帮助中找到答案（我确实看过）而且我确实问了一些软件开发人员（我使用GitHub存储文档）并且他们也不知道！
以下是该场景：我有一个GitHub存储库（称之为＆＃39; A＆＃39;）。如果有人想要进行更新，他们会将该存储库分配给他们自己的存储库（称之为＆＃39; B＆＃39;）。然后，他们可以点击“在桌面上克隆”＃39;获得本地副本。
他们在本地进行编辑，然后打开GitHub Desktop。
在GitHub桌面中，他们可以使用＆＃39; Commit to Master＆＃39;然后点击同步＆＃39;按钮。这会将它们与存储库B同步。如果他们想将编辑内容复制到存储库A，则会进入GitHub并发出拉取请求。我知道了。
但是GitHub桌面也有一个“拉动请求”。按钮，我不知道它向谁发出请求！它是存储库A还是存储库B？还是完全不同的东西？
如果它是存储库B，那么提交/同步和拉取请求按钮之间的区别是什么？
我无法尝试，因为该按钮总是灰色的（可能是因为我拥有存储库？）
用户是否可以从GitHub桌面直接向存储库A发出拉取请求 - 或者它是否总是通过存储库B的两步流程？
答案 0 :(得分：4)
Pull Request behavior will be clearer if you start thinking in terms of branches instead of repositories. A repository may contain many branches, and when you create a pull request, you pick which branch you want to merge into which other branch.
In your case, it sounds like there are two interesting branches so far:
A/masterB/masterThat is, repositories A and B each have a master branch. When you see the pull request opened from repository B to repository A, really it's being opened from branch B/master to branch A/master.
Knowing that, in fact you can open pull requests between any branches that have a common commit history. For example, if someone created an A/document_more_things branch and made some commits (and syncs, which in Git parlance would be a push from their local repository A to GitHub's remote repository A), the repository might look like this:
a - b - c # master
\
d - e - f # document_more_things
Both the master and document_more_things branches exist in repository A, without the need of a forked repository B, and the author can open a pull request from A/document_more_things to A/master. When the pull request is accepted, history will look like this, with a g merge commit:
a - b - c --------- g # master
\ /
d - e - f
Whether document_more_things is in A or B actually doesn't matter very much, because Git only cares about commits and their ancestries. If B was forked at commit C and d e f were made on B/master, we would get the same picture after the pull request from B/master to A/master as we did from A/document_more_things.
If you'd like to get a better understanding of Git's model, there are a lot of online resources to recommend: