我正在学习如何为 Github 上的开源项目做贡献。我想尝试修复一个适用于 3.x 分支的问题，但我很困惑为什么 Github Desktop 同时显示了来自源和上游的分支：
如果我正在处理一个分支，我怎么可能切换到上游仓库的分支呢？这对我来说毫无意义（但请记住，我来自 Mercurial 背景，所以也许我没有完全理解 Git 的分支 - 我认为它们以某种方式存在于版本控制之外？）。
如果上游仓库在 3.x 分支上有一些提交，而我点击了upstream/3.x，我的工作目录是否会以某种方式从这些上游提交中获得更改？我认为这没有意义，但我不明白为什么它会提供切换到上游分支。
答案1
（但请记住我来自 Mercurial 背景，所以也许我没有完全理解 Git 的分支 - 我认为它们以某种方式存在于版本控制之外？）。
Git 分支的工作方式与 Mercurial 类似书签。它们并不是不可改变地附加到提交上，而是作为指向某些提交 ID 的灵活指针（参见 Mercurial 的书签docs），因此多个存储库完全可以拥有指向同一次提交的自己的书签。
（实际上，当你推送到 GitHub 时，就会发生这种情况——首先上传提交，然后远程存储库的“主”或“主”书签（即分支）会更新以指向它们，因此现在本地和远程书签独立指向同一次提交。同样，当您从“master”创建新的本地分支时，它只是创建指向与“master”相同的提交的第二个书签。
尽管 Git 分支似乎并不像 Hg 书签那样与远程存储库保持严格同步。分歧是意料之中的，因此从远程存储库下载的分支总是使用“reponame/”命名空间，而 Hg 的文档暗示应该快速处理分歧的“foo@reponame”书签。）
如果我正在处理一个 fork 分支，怎样才能切换到上游 repo 上的一个分支？
你不只是在做一个分叉，你正在做一个叉子的叉子。您在桌面上拥有的克隆存储库与 GitHub 上的 fork 完全分开——它有自己的分支和所有内容。（“origin/”分支和“upstream/”分支实际上都不是 GH Desktop 显示的存储库的本地分支；它们只是本地缓存远程分支的副本。
Git 存储库不限于只有一个 URL 来推送/拉取 - 使用分支时通常有两个 URL，并直接从两个 URL 获取提交和分支。例如，您可以通过将“upstream/3.x”合并到本地“3.x”来集成最新的上游更改，然后推送到 GitHub 分支的“origin/3.x”。
如果上游仓库在我的 3.x 分支上分叉之前有一些提交，并且我单击了上游/3.x，那么我的工作目录是否会以某种方式从这些上游提交中获得更改？
是的，确实如此。您的桌面存储库拥有上游存储库所有分支的完整副本（截至上次获取），您可以检出它们的提交、从它们创建本地分支、将单个提交合并或挑选到本地分支等。（这比“上游”更通用，您可以配置任意数量的远程，例如跟踪其他人的开发分支。）
然而，至少使用命令行git工具，检出远程分支（无论是“origin/3.x”还是“upstream/3.x”）是暂时的操作 – 它不会自动创建您可以处理的本地分支，它只会签出“分离的”提交。您仍然可以从中创建分支，只是不是自动的。
（不过如果你尝试查看一个不存在的当地的“3.x” 分支，Git 神奇地从“origin/3.x”创建了它。）
我很久没用过 GitHub Desktop 了，所以我不知道通过 GUI 检出远程分支时会发生什么——它可能提供创建以远程分支命名的本地分支“3.x”，或者可能不会。