，那只是 means there is no absolute upstream repo or downstream repo. Those notions are always relative between two repos and depends on the way data flows:
If "yourRepo" has declared "otherRepo" as a remote one, then ：
你是 pulling from upstream "otherRepo"（"otherRepo"是“上游 from 你", and you are "下游 for otherRepo”） .
你是 pushing to upstream （"otherRepo"仍然是"upstream"，信息现在返回到） .
In term of "flow of data", your repo is at the bottom ("downstream") of a flow coming from upstream repos ("pull from") and going back to (the same or other) upstream repos ("push to").
他想说提交B是提交A的唯一子节点的唯一子节点的唯一子节点，因此将B合并到A中就足以将ref A移动到指向提交B.为什么这个方向应该被称为"upstream"而不是"downstream"，或者为什么这种纯粹的直线图的几何形状应该被描述为"directly upstream"，完全不清楚并且可能是任意的 . （ git-merge 的手册页更好地解释了这种关系，当它说"the current branch head is an ancestor of the named commit."这是Chacon应该说的那种东西 . ）
[补充说明：我一直在考虑上面引用的第一个Chacon句子和 git-merge 手册页之间的关系，而且我发现前者可能是基于对后者的误解 . 手册页继续描述使用"upstream"是合法的情况：快进经常发生在"you are tracking an upstream repository, you have committed no local changes, and now you want to update to a newer upstream revision."所以也许Chacon使用"upstream"，因为他在手册页中看到了它 . 但是在手册页中有一个远程存储库;在Chacon引用的快速转发示例中没有远程存储库，只有几个本地创建的分支 .
5 回答
在源代码控制方面，你是“ downstream " when you copy (clone, checkout, etc) from a repository. Information flowed "下游” .
当您进行更改时，通常需要将它们发送回“ upstream ”，以便它们进入该存储库，以便从同一来源拉出的每个人都可以使用所有相同的更改 . 这主要是每个人如何协调工作而不是源控制技术要求的社会问题 . 您希望将更改纳入主项目，这样您就无法跟踪不同的开发线 .
有时您会阅读有关提交“上游”更改的包或发布经理（人员，而不是工具） . 这通常意味着他们必须调整原始来源，以便他们可以为他们的系统创建一个包 . 他们不想继续进行这些更改，因此如果他们将它们“上游”发送到原始源，他们就不必在下一个版本中处理相同的问题 .
当您阅读git tag man page时：
，那只是 means there is no absolute upstream repo or downstream repo. Those notions are always relative between two repos and depends on the way data flows:
If "yourRepo" has declared "otherRepo" as a remote one, then ：
你是 pulling from upstream "otherRepo"（"otherRepo"是“上游 from 你", and you are "下游 for otherRepo”） .
你是 pushing to upstream （"otherRepo"仍然是"upstream"，信息现在返回到） .
注意"from"和"for"：你不仅仅是"downstream"，你是“for / from”的下游，因此是相对的方面 .
DVCS（分布式版本控制系统）扭曲是：你不知道下游实际上是什么，除了你自己的repo相对于你声明的远程仓库 .
你知道上游是什么（你正在拉动或推动的仓库）
你不知道下游是由什么组成的（另一个回购拉动或推到你的回购） .
基本上：
In term of "flow of data", your repo is at the bottom ("downstream") of a flow coming from upstream repos ("pull from") and going back to (the same or other) upstream repos ("push to").
您可以在git-rebase man page中看到"RECOVERING FROM UPSTREAM REBASE"段落中的插图：
这意味着你是 pulling from an "upstream" repo where a rebase took place ，并且你（"downstream" repo）卡在后果中（许多重复提交，因为上游的分支重新创建了本地相同分支的提交） .
这是不好的，因为对于一个"upstream" repo，可以有 many 下游回购（即从上游回收的回购，具有重新分支），所有这些都有可能处理重复提交 .
Again, with the "flow of data" analogy, in a DVCS, one bad command "upstream" can have a "ripple effect" downstream.
注意：这不仅限于数据 .
It also applies to parameters ，因为git命令（比如"porcelain"）经常在内部调用其他git命令（"plumbing"） . 见rev-parse man page：
上游（与之相关）跟踪
对于GIT工具套件，术语 upstream 也有一些明确的含义，特别是相对于 tracking
例如 ：
origin（你在github上的分叉存储库） ）和upstream（你分叉的github上的回购） . 这些只是可互换的名称，只有'git@...' url标识它们 .假设想要将远程分支origin / master设置为您已检出的本地主分支的跟踪分支 . 刚发出：
上游和推送（Gotcha）
看看git-config(1) Manual Page
这是一些非正式的术语 .
就Git而言，每个其他存储库都只是一个远程存储库 .
一般来说，上游是您克隆的地方（原点） . 下游是将您的作品与其他作品整合在一起的任何项目 .
这些条款不仅限于Git存储库 .
例如，Ubuntu是Debian衍 生产环境 品，因此Debian是Ubuntu的上游产品 .
上游被称为有害
唉，另一个使用"upstream"，其他答案在这里没有得到，即在回购中引用提交的父子关系 . _2843830中的Scott Chacon特别容易出现这种情况，结果很不幸 . 不要模仿这种说法 .
例如，他说合并导致快速发生，因为这发生了
他想说提交B是提交A的唯一子节点的唯一子节点的唯一子节点，因此将B合并到A中就足以将ref A移动到指向提交B.为什么这个方向应该被称为"upstream"而不是"downstream"，或者为什么这种纯粹的直线图的几何形状应该被描述为"directly upstream"，完全不清楚并且可能是任意的 . （
git-merge的手册页更好地解释了这种关系，当它说"the current branch head is an ancestor of the named commit."这是Chacon应该说的那种东西 . ）事实上，Chacon自己似乎后来使用“下游”来表示完全相同的事情，当他谈到重写已删除提交的所有子提交时：
基本上，当他提到随着时间的推移历史时，他似乎并没有清楚地知道“上游”和“下游”的含义 . 这种使用是非正式的，然后，不要鼓励，因为它只是令人困惑 .
很明显，每个提交（除了一个）至少有一个父母，父母的父母就是祖先;在另一个方向，承诺有孩子和后代 . 这是公认的术语，并且明确地描述了图形的方向性，因此当您想要描述提交在回购的图形几何中如何相互关联时，就是谈话的方式 . 在这种情况下，不要松散地使用“上游”或“下游” .
[补充说明：我一直在考虑上面引用的第一个Chacon句子和
git-merge手册页之间的关系，而且我发现前者可能是基于对后者的误解 . 手册页继续描述使用"upstream"是合法的情况：快进经常发生在"you are tracking an upstream repository, you have committed no local changes, and now you want to update to a newer upstream revision."所以也许Chacon使用"upstream"，因为他在手册页中看到了它 . 但是在手册页中有一个远程存储库;在Chacon引用的快速转发示例中没有远程存储库，只有几个本地创建的分支 .