git fetch 和 git push 之间存在不对称，这会让您感到困惑。 （这与 GitHub 分支方面并不真正相关：使用任何普通的克隆集都会得到相同的结果。）
你想做的很简单：
-
对具有不同分支名称的存储库运行 git fetch。这会在您自己的个人存储库中为您从中获取的存储库中的每个 branch 名称生成一个 remote-tracking 名称。
在您的情况下，您将此存储库称为upstream，因此您将运行git fetch upstream。这将创建或更新各种upstream/* 名称。您可能希望在此处使用git fetch --prune，以防他们删除一些分支名称，以便您自己的 Git 将删除相应的远程跟踪名称：例如，如果他们 (upstream)曾经有一个名为gronk 的分支，现在他们不再有一个名为gronk 的分支，但是你的Git 昨天创建了upstream/gronk，当时他们确实拥有了他们的gronk，这个git fetch --prune upstream将删除upstream/gronk。
（如果您愿意，可以像我一样，只需在您的个人全局 Git 配置中设置 fetch.prune，这样所有 git fetch 操作就像您使用过 git fetch --prune 一样。这样可以节省在每个时间。）
-
对于现在出现在您自己的存储库中的每个 remote-tracking 名称，您希望其 分支 名称出现在您的 GitHub 分支中，请使用 git push 创建您的 GitHub 分支中的该分支名称，指向您本地存储库中该远程跟踪名称现在找到的相同提交。
例如，您现在在您的存储库中看到upstream/stage_demo（在您的计算机上本地）。这是一个远程跟踪名称。它是在上面的步骤 1 中创建的。您希望在您的 GitHub fork 中看到分支名称 stage_demo。你只需要让 GitHub 使用他们的 Git 来设置你的 GitHub 分支的 stage_demo 名称——这将是他们的新分支名称——基于你自己的 upstream/stage_demo 名称。
要完全明确，确定所有内容以确保不会出错，您需要：
git push origin refs/remotes/upstream/stage_demo:refs/heads/stage_demo
（假设您将 GitHub 存储库称为 origin）。但是，您几乎可以肯定地避开稍短的：
git push origin upstream/stage_demo:refs/heads/stage_demo
请注意，此不会创建一个名为stage_demo 的本地 分支。如果你想这样做，你可以这样做，而不是上面的第 2 步，只需：
git checkout stage_demo
或：
git checkout -t upstream/stage_demo
（或 git switch 的等价物，在 Git 2.23 或更高版本中）。完成后，您可以使用更简单的：
git push origin stage_demo
让您的 Git 将提交发送到您的 GitHub 分支并请求 GitHub 在您的 GitHub 分支中创建此分支名称。
更多关于这种不对称的信息
这里发生的事情很简单。 git fetch 和 git push 都是通过让你的 Git 调用其他 Git 来工作的。您的 Git 从 (git push) 读取或写入 (git fetch) 您的 Git 存储库；这里的数据传输方向由您运行的命令决定。不对称之处在于，在获取或发送了一些提交（可能为空）之后，传输完成：
-
git fetch：在您的存储库中创建或更新远程跟踪名称；
-
git push：在他们的存储库中创建或更新分支名称。
远程跟踪名称是类似于origin/master 和upstream/stage_demo 的名称。它们由两部分组成：一个远程，在这种情况下是origin 或upstream，以及一个分支名称，在这种情况下是master 或stage_demo。遥控器是您提供给git fetch 的遥控器。分支名称是在 他们的 Git 中找到的。
你的git fetch没有写在你的分支名称上。那是因为你的分支名称是你的。他们发现你关心的提交。他们的分支名称可以找到他们关心的提交。你和他们只关心相同的提交如果和何时你决定是这种情况。在其他时候，你和他们特别关心不同的提交，你的 Git 不应该仅仅因为你接受了他们的提交而忘记了你的提交。当您进行 new 提交时，这一点尤其重要：他们不会记住它们，因此如果您的 Git 更新了您的 branch 名称，您的 Git 会 忘记您的新提交。这将是非常糟糕的。
但git push 不会创建或更新任何类型的“推送跟踪名称”。 （也许它应该——或者应该能够——考虑到我们使用 GitHub 的方式，但事实并非如此，因为它们根本不存在。）推送创建或更新它们的 branch 名称。这意味着他们不能创建新的提交——这在很多情况下是正确的，因为你正在推送到你的分支，而不是你的上游。除了你之外没有人可以在你的fork中进行新的提交，你通常通过在本地进行提交，然后使用git push发送它们来做到这一点。
如果您只是将自己的 GitHub 分支用作第二个/备份存储系统，用于在您自己的计算机上的自己的存储库中进行的提交，这一切都可以正常工作。但是在这里，您使用自己的 GitHub 分支来存储您的提交和 来存储您称为上游的 他们的 提交。所以现在你必须做这个三角工作流：
- 从您的上游获取他们的提交到您的计算机；那么
- 将他们现在在您计算机上的提交发送到您的 GitHub 存储库
这需要两步或更多步的舞蹈。
有一个案例缺乏这种不对称性
如果您不喜欢这一切，有办法解决。 Git 有一个叫做镜像克隆的东西。镜像克隆不使用远程跟踪名称。当您在这样的克隆上运行 git fetch 时，它会更新克隆的 分支 名称，以便克隆充当其他克隆的镜像。
问题在于镜像克隆不能通过任何机制接收新工作，而不仅仅是从你克隆它的地方获取它。这是因为，在将所有自己的分支名称都绑定到另一个存储库后，您插入其中的任何新提交都将立即被任何git fetch 丢失除非这些新提交已经在其中的克隆中你在取。因此，您所做的任何新提交都必须先直接发送到origin，然后再将它们带回镜像克隆。
换句话说，镜像克隆在这里并不好。它们主要用作本地缓存。例如，假设您的公司在伦敦、纽约、旧金山和新加坡设有办事处。每个位置都有一百个或更多的工人，他们将克隆、获取和合并等等：大量的阅读。无需每个人每次都直接从伦敦获取，您可以在纽约、旧金山和新加坡进行镜像克隆，每 15 分钟更新一次镜像克隆，并让每个办公室从本地镜像获取，这永远不会超过 15 分钟日期。