“下游”和“上游”的定义

Posted 2021-05-03

我已经开始玩Git并遇到过“上游”和“下游”这两个词。我之前见过这些，但从未完全理解它们。这些术语在SCM（Software Configuration Management工具）和源代码的上下文中意味着什么？

答案

在源代码控制方面，当您从存储库复制（克隆，签出等）时，您处于“下游”。信息流向“下游”给您。

当您进行更改时，您通常希望将它们发送回“上游”，以便它们进入该存储库，以便从同一来源拉出的每个人都在处理所有相同的更改。这主要是每个人如何协调工作而不是源控制技术要求的社会问题。您希望将更改纳入主项目，这样您就无法跟踪不同的开发线。

有时您会阅读有关提交“上游”更改的包或发布经理（人员，而不是工具）。这通常意味着他们必须调整原始来源，以便他们可以为他们的系统创建一个包。他们不想继续进行这些更改，因此如果他们将它们“上游”发送到原始源，他们就不必在下一个版本中处理相同的问题。

另一答案

当你在git tag man page阅读时：

git的一个重要方面是它是分布式的，并且分布很大意味着系统中没有固有的“上游”或“下游”。

，这仅仅意味着没有绝对的上游回购或下游回购。 这些概念在两个回购之间总是相对的，取决于数据的流动方式：

如果“yourRepo”已将“otherRepo”声明为远程，则：

• 你是从上游“otherRepo”拉出来的（“otherRepo”是“你的上游”，而你是“otherRepo的下游”）。
• 你正推向上游（“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 ''

• 正如已经说过的，你可能有一个本地存储库的任意数量的遥控器，例如，如果你从github分叉存储库，然后发出一个“拉取请求”，你肯定至少有两个：origin（你的分叉回购在github上）和upstream（你分享的github上的回购）。这些只是可互换的名称，只有'git @ ...'url标识它们。

你的.git/configreads：

   [remote "origin"]
       fetch = +refs/heads/*:refs/remotes/origin/*
       url = [e-mail]:myusername/reponame.git
   [remote "upstream"]
       fetch = +refs/heads/*:refs/remotes/upstream/*
       url = [e-mail]:authorname/reponame.git

• 另一方面，@ {upstream}对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

git-push(1) Manual Page：

   -u
   --set-upstream

对于每个最新或成功推送的分支，添加上游（跟踪）引用，由无参数git-pull（1）和其他命令使用。有关更多信息，请参阅git-config（1）中的branch.<name>.merge。

git-config(1) Manual Page：

   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。如果您不在任何分支上，也会使用原点。

上游和推送（Gotcha）

看看git-config(1) Manual Page

   git config --global push.default upstream
   git config --global push.default tracking  (deprecated)

这是为了防止意外推到你尚未准备推进的树枝上。

另一答案

这是一些非正式的术语。

就Git而言，每个其他存储库都只是一个远程存储库。

一般来说，上游是您克隆的地方（原点）。下游是将您的作品与其他作品整合在一起的任何项目。

这些条款不仅限于Git存储库。

例如，Ubuntu是Debian衍生产品，因此Debian是Ubuntu的上游产品。

另一答案

Upstream Called Harmful

唉，另一个使用“上游”，其他答案在这里没有得到，即在回购中引用提交的亲子关系。 Pro Git book的Scott Chacon特别容易出现这种情况，结果很不幸。不要模仿这种说法。

例如，他说合并导致快速发生，因为这发生了

您合并的分支指向的提交直接位于您所在的提交的上游

他想说提交B是提交A的唯一子节点的唯一子节点的唯一子节点，因此将B合并到A中就足以将ref A移动到指向提交B.为什么这个方向应该被称为“上游”而不是“下游”，或者为什么这种纯直线图的几何形状应该被描述为“直接上游”，完全不清楚并且可能是任意的。 （当git-merge说“当前的分支头是命名提交的祖先”时，git-merge的手册更好地解释了这种关系。这就是Chacon应该说的那种。）

事实上，Chacon自己似乎后来使用“下游”来表示完全相同的事情，当他谈到重写已删除提交的所有子提交时：

您必须重写6df76下游的所有提交，以从Git历史记录中完全删除此文件

基本上，当他提到随着时间的推移历史时，他似乎并没有清楚地知道“上游”和“下游”的含义。这种使用是非正式的，然后，不要鼓励，因为它只是令人困惑。

很明显，每个提交（除了一个）至少有一个父母，父母的父母就是祖先;在另一个方向，承诺有孩子和后代。这是公认的术语，并且明确地描述了图形的方向性，因此当您想要描述提交在回购的图形几何中如何相互关联时，就是谈话的方式。在这种情况下，不要松散地使用“上游”或“下游”。

[补充说明：我一直在思考上面引用的第一个Chacon句子和qazxswpoi手册页之间的关系，我发现前者可能是基于对后者的误解。手册页继续描述使用“上游”是合法的情况：快速转发经常发生在“您正在跟踪上游存储库，您没有提交本地更改，现在您想要更新到更新上游修订。“所以也许Chacon使用“上游”，因为他在手册页中看到了它。但是在手册页中有一个远程存储库;在Chacon引用的快速转发示例中没有远程存储库，只有几个本地创建的分支。