为什么“原始”存储库被称为“上游”（经常）？答案

【问题标题】：Why is the "original" repository called "upstream" (frequently)?为什么“原始”存储库被称为“上游”（经常）？
【发布时间】：2012-09-14 21:49:21
【问题描述】：

在 bitbucket/github 上 fork 时，您有时需要将原始存储库添加为远程存储库，以便您可以将最近的更改拉入您的 fork。我在其他帖子（例如How do I update a GitHub forked repository?）中看到，原来称为上游。

为什么原始版本为“上游”，而 github/bitbucket 托管的分支为“起源”？还有其他我们应该注意的约定吗？

我想这可能有助于将其形象化为“很难逆流而上”，因此更难逆流而上……但是，这是一个不恰当的类比。

【问题讨论】：

我认为这是因为主要目标是在存储库中收集开发和调试过的代码，这些代码是为团队原创的。所以你做的主要事情 - 是推动。只是一个想法......

标签： git mercurial github bitbucket

【解决方案1】：

类比是指变更的影响会向下游传播，但您不能使变更向上游传播。

有一个类似问题的答案here。

【讨论】：

除非您可以并且经常确实将最初写入下游的更改写入上游存储库。
@delnan ..除非河里有[太多]叉子;-)
@delnan 好吧，这不是重点吗，您必须在上游进行更改？
不，您不必再次进行更改。你只需要让上游维护者来拉它，因为你可能没有上游的写权限。或者，如果您有权这样做，您只需推动即可。在这两种情况下，它都是 DVCS 的原始操作之一，没什么特别的，最重要的是遵循 DRY 原则。只需单击一个按钮，您就可以在上游更改一千行。

【解决方案2】：

上游是软件开发（尤其是开源项目）中的一个常用术语，指的是你所依赖的原始项目。

这个术语用来表达代码变化“流”向一个方向的想法；对于项目分叉，从原始项目到您的分叉副本。

例如，Linux 发行版为其用户打包软件，有时会对代码应用小补丁。当用户在其中一个包中发现缺陷并将其报告给发行版的错误跟踪器时，如果问题过于广泛或打包者无法解决，它可能会被标记为“上游”以传达它应该转发给软件原作者待解决。或者，如果发行版可以应用小的修正，最好将其“转发到上游”，以便同一软件产品的其他用户可以从中受益。

【讨论】：