我已经开始玩Git并遇到过“上游”和“下游”这两个词。我之前见过这些，但从未完全理解它们。这些术语在SCM（Software Configuration Management工具）和源代码的上下文中意味着什么？
在源代码控制方面，当您从存储库复制（克隆，签出等）时，您处于“下游”。信息流向“下游”给您。
当您进行更改时，您通常希望将它们发送回“上游”，以便它们进入该存储库，以便从同一来源拉出的每个人都在处理所有相同的更改。这主要是每个人如何协调工作而不是源控制技术要求的社会问题。您希望将更改纳入主项目，这样您就无法跟踪不同的开发线。
有时您会阅读有关提交“上游”更改的包或发布经理（人员，而不是工具）。这通常意味着他们必须调整原始来源，以便他们可以为他们的系统创建一个包。他们不想继续进行这些更改，因此如果他们将它们“上游”发送到原始源，他们就不必在下一个版本中处理相同的问题。
当你在git tag man page阅读时：
git的一个重要方面是它是分布式的，并且分布很大意味着系统中没有固有的“上游”或“下游”。
，这仅仅意味着没有绝对的上游回购或下游回购。 这些概念在两个回购之间总是相对的，取决于数据的流动方式：
如果“yourRepo”已将“otherRepo”声明为远程，则：
注意“从”和“为”：你不仅仅是“下游”，你是“下游/为”，因此相对方面。
DVCS（分布式版本控制系统）扭曲是：你不知道下游实际上是什么，除了你自己的repo相对于你声明的远程仓库。
基本上：
在“数据流”方面，您的仓库位于来自上游回购（“拉出”）并返回（相同或其他）上游回购（“推送到”）的流的底部（“下游”） ）。
您可以在git-rebase man page中看到一个插图，其中包含“从上游恢复中恢复”的段落：
这意味着你正在从一个发生rebase的“上游”仓库中撤出，而你（“下游”仓库）仍然存在后果（许多重复提交，因为上游的分支重新创建了同一分支的提交你在当地）。
这是不好的，因为对于一个“上游”仓库，可能存在许多下游仓库（即，从上游仓库撤回，具有重新分支的仓库），所有这些仓库都有可能处理重复提交。
同样，对于“数据流”类比，在DVCS中，一个坏命令“上游”可以在下游具有“波纹效应”。
注意：这不仅限于数据。
它也适用于参数，因为git命令（如“瓷器”命令）经常在内部调用其他git命令（“plumbing”命令）。见rev-parse man page：
许多git ceramicish命令混合使用标记（即以短划线'
-'开头的参数）和参数，这些参数用于内部使用的底层git rev-list命令，以及用于git rev-list下游的其他命令的标志和参数。此命令用于区分它们。
对于GIT工具套件而言，上游一词也具有一些明确的含义，特别是与跟踪相关
例如 ：
$git rev-list --count --left-right "@{upstream}"...HEAD >4 12将打印（最后一个缓存的值）当前工作分支后面（左）和前面（右）的提交数，相对于当前跟踪此本地分支的远程分支（如果有）。否则将打印错误消息：
>error: No upstream branch found for ''
origin（你的分叉回购在github上）和upstream（你分享的github上的回购）。这些只是可互换的名称，只有'git @ ...'url标识它们。你的
.git/configreads：[remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = [email protected]:myusername/reponame.git [remote "upstream"] fetch = +refs/heads/*:refs/remotes/upstream/* url = [email protected]:authorname/reponame.git
它是“所说的遥控器”上的“分支”（如果有的话），它跟踪“本地存储库”上的“当前分支”。
这是你在没有参数的情况下发布普通
git fetch/git pull时获取/拉出的分支。
假设想要将远程分支origin / master设置为您已检出的本地主分支的跟踪分支。刚发出：
$ git branch --set-upstream master origin/master > Branch master set up to track remote branch master from origin.这在
.git/config中添加了2个参数：[branch "master"] remote = origin merge = refs/heads/master现在尝试（提供'上游'遥控器有'dev'分支）
$ git branch --set-upstream master upstream/dev > Branch master set up to track remote branch dev from upstream.
.git/config现在写道：[branch "master"] remote = upstream merge = refs/heads/dev-u --set-upstream对于每个最新或成功推送的分支，添加上游（跟踪）引用，由无参数git-pull（1）和其他命令使用。有关更多信息，请参阅git-config（1）中的
branch.<name>.merge。branch.<name>.merge与
branch.<name>.remote一起定义给定分支的上游分支。它告诉git fetch / git pull / git rebase哪个分支合并，也可以影响git push（参见push.default）。 \（...）branch.<name>.remote当在分支<name>中时，它会告诉git fetch和git push从哪个远程提取/推送到。如果未配置远程，则默认为origin。如果您不在任何分支上，也会使用原点。
git config --global push.default upstream git config --global push.default tracking (deprecated)这是为了防止意外推到你尚未准备推进的树枝上。
这是一些非正式的术语。
就Git而言，每个其他存储库都只是一个远程存储库。
一般来说，上游是您克隆的地方（原点）。下游是将您的作品与其他作品整合在一起的任何项目。
这些条款不仅限于Git存储库。
例如，Ubuntu是Debian衍生产品，因此Debian是Ubuntu的上游产品。
唉，另一个使用“上游”，其他答案在这里没有得到，即在回购中引用提交的亲子关系。 Pro Git book的Scott Chacon特别容易出现这种情况，结果很不幸。不要模仿这种说法。
例如，他说合并导致快速发生，因为这发生了
您合并的分支指向的提交直接位于您所在的提交的上游
他想说提交B是提交A的唯一子节点的唯一子节点的唯一子节点，因此将B合并到A中就足以将ref A移动到指向提交B.为什么这个方向应该被称为“上游”而不是“下游”，或者为什么这种纯直线图的几何形状应该被描述为“直接上游”，完全不清楚并且可能是任意的。 （当git-merge说“当前的分支头是命名提交的祖先”时，git-merge的手册更好地解释了这种关系。这就是Chacon应该说的那种。）
事实上，Chacon自己似乎后来使用“下游”来表示完全相同的事情，当他谈到重写已删除提交的所有子提交时：
您必须重写6df76下游的所有提交，以从Git历史记录中完全删除此文件
基本上，当他提到随着时间的推移历史时，他似乎并没有清楚地知道“上游”和“下游”的含义。这种使用是非正式的，然后，不要鼓励，因为它只是令人困惑。
很明显，每个提交（除了一个）至少有一个父母，父母的父母就是祖先;在另一个方向，承诺有孩子和后代。这是公认的术语，并且明确地描述了图形的方向性，因此当您想要描述提交在回购的图形几何中如何相互关联时，就是谈话的方式。在这种情况下，不要松散地使用“上游”或“下游”。
[补充说明：我一直在思考上面引用的第一个Chacon句子和qazxswpoi手册页之间的关系，我发现前者可能是基于对后者的误解。手册页继续描述使用“上游”是合法的情况：快速转发经常发生在“您正在跟踪上游存储库，您没有提交本地更改，现在您想要更新到更新上游修订。“所以也许Chacon使用“上游”，因为他在手册页中看到了它。但是在手册页中有一个远程存储库;在Chacon引用的快速转发示例中没有远程存储库，只有几个本地创建的分支。