问题的出现的原因是用户在克隆一个分叉后，需要显式地添加一个远程upstream，以git add remote "原始分叉的仓库"的方式添加。这个upstream成为你的上游，你主要从上游获取和合并。其他任何业务，比如从本地推送到上游，都应该使用拉取请求来完成。

解决方法是当你尝试从新创建的分支推送到远程仓库时，会出现fatal: The current branch branchName has no upstream branch. push the current branch and set the remote as upstream的错误提示。这时可以使用git push --set-upstream origin branchName的命令来解决。这里的upstream指的是原始分叉仓库。如果你没有进行分叉，就没有upstream。

总结起来，upstream指的是原始分叉仓库，通过设置远程upstream可以方便地从上游获取和合并代码。如果没有进行分叉，则没有upstream。

GitHub是一个非常流行的代码托管平台，许多开发人员使用它来协作开发项目。在GitHub上，有两个重要的概念，即"origin"和"upstream"。然而，很多人对这两个概念之间的区别感到困惑。下面将解释这两者的区别，并提供解决方法。

首先，"origin"代表的是一个代码库的"fork"，也就是说，它是一个拷贝。当你在GitHub上复制一个项目时，你将得到一个自己的代码库，这个代码库就是"origin"。可以说，"origin"是你自己的代码库，你可以对它进行任何修改。

而"upstream"则表示被"fork"的代码库，也就是你复制的那个项目的原始代码库。"upstream"代表着原始代码库的更新和变化。当原始代码库发生变化时，你可以通过"upstream"来同步这些变化到你自己的代码库中。

那么，为什么需要区分"origin"和"upstream"呢？这是因为"origin"和"upstream"代表着不同的代码库，有着不同的作用。你可以在"origin"中进行任何修改和实验，而"upstream"则是用来同步原始代码库的变化。这有助于保持你的代码库与原始代码库保持同步，以便及时获取最新的更新。

解决方法是通过一些命令来管理"origin"和"upstream"。首先，你需要将原始代码库添加为"upstream"的远程仓库。可以使用以下命令：

git remote add upstream <原始代码库的URL>

然后，你可以使用以下命令将"upstream"的变化同步到你的代码库中：

git fetch upstream
git merge upstream/master

这样，你的代码库就会与原始代码库保持同步。

，"origin"代表你自己的代码库，可以进行任何修改和实验；"upstream"代表原始代码库，用于同步原始代码库的变化。通过管理"origin"和"upstream"，你可以保持你的代码库与原始代码库同步，获取最新的更新。

在GitHub上，关于"origin"和"upstream"之间的区别应该在fork一个GitHub repo的情况下进行理解（在在GitHub上fork一个repo，然后在本地克隆该fork）。

• "upstream"通常指的是您fork的原始repo

  （关于"upstream"术语的更多信息，请参见"上游"和"下游"的定义）

• "origin"是您的fork：您在GitHub上的自己的repo，是GitHub上原始repo的克隆

根据GitHub页面的描述：

当克隆一个repo时，它有一个默认的名为"origin"的远程仓库，该远程仓库指向您在GitHub上的fork，而不是该fork的原始repo。

要跟踪原始repo，您需要添加另一个名为"upstream"的远程仓库

git remote add upstream https://github.com/<aUser>/<aRepo.git>

（其中"aUser/aRepo"是原始创建者和存储库的引用，您已经fork了它）

注意：自2021年9月起，GitHub不再支持未经身份验证的git协议（git://...）的9418端口。

您将使用"upstream"从原始repo获取（fetch）（以便将本地副本与您想要贡献的项目保持同步）。

git fetch upstream

（仅使用"git fetch"会默认从"origin"获取，这不是所需的）

您将使用"origin"来pull和push，因为您可以贡献到自己的存储库。

git pull
git push

（同样，不带参数，默认使用'origin'）

您将通过发起一个pull request来向"upstream" repo贡献代码。

了解"upstream"的常规含义也很有帮助：stackoverflow.com/questions/2739376/…

值得一提的是，在GitHub上，将origin作为主存储库，并使用GitHub用户名作为您和其他fork的远程名称更加合理。像defunkt.io/hub这样的工具就是这么做的，这样可以更加统一地处理存储库并在fork之间进行协作。

没错，但我喜欢不用包装器来使用Git，所以我暂时保留这种约定（upstream和origin）。

这是我见过的关于fork工作流程的最好解释。你得到了我的赞。

解释得非常清楚易懂。这正是我在寻找的答案。

那使用云端（hub/bucket等）作为主要源头的场景呢，将软件包克隆到其他地方的服务器上进行托管。这个服务器上的repo是主要的开发下游，甚至可能是唯一的，但不希望被限制在此。而且你希望云端成为明显的上游。但是你会添加一个origin，设置它与upstream相同，还是在这个特殊的prod（生产）repo中省略origin？从那里克隆到他们的用户空间，他们的origin变成了这个服务器的repo（prod），但问题是服务器repo的origin，而不是开发人员的克隆。

哦，在我的场景中，云端是你的图表中的“原始”，服务器是你的“Fork”。我是这么想的。这样，另一个团队可以在另一台服务器上fork，如果需要更多的团队，可以重复这个过程，比如前后端分离，或其他原因。那么，fork可以没有origin吗，还是需要设置（为了方便起见）与上游相同的origin？还是有更好的建议？

“所以，fork可以没有origin吗”：最好是fork的origin是原始repo，以便记住这个fork是从哪个repo派生的。

不确定如果只有upstream，没有origin的情况下会发生什么，您会知道origin将是那个，当运行git remote -v时，如果只指定了upstream，除非是指其他时间，也许是在push时？这可能是我的问题，如果只有upstream，没有origin，那在推送/拉取时如何影响，如果我只有upstream，没有origin？或者这可能是一种正确（替代）的方式来暗示origin，通过不指定，只指定upstream？或者说，这是一种反模式的使用方式，为了方便起见，只是双重指定，或者我应该只添加origin并将upstream留空以供prod使用？

在这一点上，最好您提出一个新问题，其中清楚地阐述您的具体情况。

- 我在Github上创建了一个repo（没有fork）。看到所有这些（包括upstream和origin分支）是正常的吗？因为我添加了指向自己repo的upstream。如果我理解正确的话，它指向的是同一个repo，所以当我提交到任何一个时，我本质上是写入同一个repo对吧？

如果git remote -v显示origin和upstream的URL相同，那么是的，您正在推送到同一个远程repo。

- 刚刚检查了一下——它们确实是相同的。非常感谢！

这是否意味着git fetch将从upstream获取，而git pull将从origin获取？

默认情况下不是的：仅使用fetch会从您的fork（即origin）获取。但是随时可以选择从upstream获取：git fetch upstream。

我可能遗漏了这一点，但是"upstream"是否有特定的含义，还是在使用git时只是一种约定俗称的名称，例如，可以使用任何名称代替它吗？

这是一种命名约定，用于引用您fork的原始repo。请参见"upstream"的定义（stackoverflow.com/a/2749166/6309）。您可以使用其他名称，但通常使用的是upstream。

因此，假设我是在一个分支上（也在repo上）独立工作，那么我不需要将该分支设置为"upstream"。只需在本地工作-》git-add-》git-commit-》git-push，对吗？

是的，这是正确的。在这种情况下不需要fork。

谢谢，我对这个"upstream"选项感到非常困惑。当我fork别人的repo/branch时，因为Git将原始repo的副本实例化到我的副本中，所以需要它。然后，通过"upstream"选项告诉Git将我拥有的副本与原始副本链接起来，这样我就可以拉取原始所有者可能进行的更改，对吗？

是的，这是一般的想法。

嘿，解释得非常好。关于fork的工作流程还有一个问题...我知道本地"master"分支会自动与远程追踪分支"origin/master"关联，因为在fork之后克隆了origin。但是，将本地"master"分支与"upstream/master"关联是否更有意义，因为人们经常会执行fetch以同步两者？我不认为经常需要将本地"master"与"origin/master"的更新保持同步。此外，命令"git branch -vv"将显示本地"master"相对于"upstream/commit"落后了多少提交。

我同意，但问题在于Git工具本身并不知道它克隆的是一个fork（"fork"是GitHub的一个功能）。因此，它只会将"main"的上游分支设置为"origin/main"，而不知道可能存在一个值得引用的上游原始存储库。

很棒的答案。小提示：最近似乎有所更改，git://github.com/<aUser>/<aRepo.git>应该更改为https://github.com/<aUser>/<aRepo.git>？至少前者对我无效，但后者有效。

谢谢您的反馈，是的，git://不再被支持了。我已相应地编辑了答案，并附上了一个链接，说明为什么不再有git://。