"下游"和"上游"的定义

Question

我已经开始玩Git并遇到过"上游"和"下游"这两个词.我之前见过这些,但从未完全理解它们.这些术语在SCM(软件配置管理工具)和源代码的上下文中意味着什么？

Answer 1

在源代码控制方面,当您从存储库复制(克隆,签出等)时,您处于" 下游 ".信息流向"下游"给您.

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

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

Answer 2

当您在git tag手册页中阅读时:

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

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

如果"yourRepo"已将"otherRepo"声明为远程,则:

• 您正在从上游拉 "otherRepo"("otherRepo"是"上游从你",你是"下游用于 otherRepo").
• 你正推向上游("otherRepo"仍然是"上游",现在信息可以回到上游).

注意"从"和"为":你不仅仅是"下游",你是"下游/为 ",因此相对方面.

DVCS(分布式版本控制系统)扭曲是:你不知道下游实际上是什么,除了你自己的repo相对于你声明的远程仓库.

• 你知道上游是什么(你正在拉动或推动的回购)
• 你不知道下游是由什么组成的(另一个回购拉动或推动你的回购).

基本上:

在" 数据流 "方面,您的仓库位于来自上游回购("拉出")并返回(相同或其他)上游回购("推送到")的流的底部("下游") ).

您可以在git-rebase手册页中看到"从上游重新恢复"段落中的插图:

这意味着你正在从一个发生rebase的"上游"仓库中撤出,而你("下游"仓库)仍然存在后果(许多重复提交,因为上游的分支重新创建了同一分支的提交你在当地).

这是不好的,因为对于一个"上游"回购,可能有许多下游回购(即从上游回收利用重新分支的回购),所有这些都有可能处理重复提交.

同样,对于"数据流"类比,在DVCS中,一个坏命令"上游"可以在下游具有" 波纹效应 ".

注意:这不仅限于数据.
它也适用于参数,因为git命令(如"瓷器"命令)经常在内部调用其他git命令("plumbing"命令).见rev-parse手册页:

许多git ceramicish命令混合使用标志(即以短划线开头的参数-)和参数,这些参数用于git rev-list内部使用的基础命令,以及它们在下游使用的其他命令的标志和参数git rev-list.此命令用于区分它们.

Answer 3

上游(与之相关)跟踪

对于GIT工具套件而言,上游一词也具有一些明确的含义,特别是与跟踪相关

例如 :

   $git rev-list --count --left-right "@{upstream}"...HEAD
   >4   12

将打印(最后一个缓存的值)当前工作分支后面(左)和前面(右)的提交数,相对于当前跟踪此本地分支的远程分支(如果有).否则将打印错误消息:

    >error: No upstream branch found for ''

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

你的.git/config读物:

   [remote "origin"]
       fetch = +refs/heads/*:refs/remotes/origin/*
       url = git@github.com:myusername/reponame.git
   [remote "upstream"]
       fetch = +refs/heads/*:refs/remotes/upstream/*
       url = git@github.com: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.

这增加了2个参数.git/config:

   [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)手册页:

   -u
   --set-upstream

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

git-config(1)手册页:

   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)手册页

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

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

Answer 4

这是一些非正式的术语.

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

一般来说,上游是您克隆的地方(原点).下游是将您的作品与其他作品整合在一起的任何项目.

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

例如,Ubuntu是Debian衍生产品,因此Debian是Ubuntu的上游产品.

Answer 5

上游称为有害

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

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

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

他想说提交B是提交A的唯一子节点的唯一子节点的唯一子节点,因此将B合并到A中就足以将ref A移动到指向提交B.为什么这个方向应该被称为"上游"而不是"下游",或者为什么这种纯直线图的几何形状应该被描述为"直接上游",完全不清楚并且可能是任意的.(该手册页git-merge时,它说,很好地解释这种关系的一个更好的工作"当前分支头的祖先命名的承诺."这是哪门子事查孔应该说.)

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

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

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

很明显,每个提交(除了一个)至少有一个父母,父母的父母就是祖先; 在另一个方向,承诺有孩子和后代.这是公认的术语,并说明该图明确的方向性,所以这是说话的时候你想描述如何犯下涉及到另一个回购的图形几何之路的.在这种情况下,不要松散地使用"上游"或"下游".

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

Answer 6

使用河流的类比，我们可以沿着我们的上游资源，直到找到源头（溪流或河流的源头）。

\n

继续以河流进行类比，下游是河流中水流的方向。下坡。

\n

所以，如果我分叉某人的项目，我分叉的项目就是上游的。我的叉子在下游。

\n

如果有人分叉我的分叉项目，那么我的分叉相对于我的项目的分叉成为上游。

\n

而我的叉子的叉子就变成了下游。

\n

示例时间！

\n\n

假设Project BforkProject A和Project Cfork Project B。

\n

然后，Project A就是上游项目。

\n

Project B是相对于 的下游项目Project A。

\n

Project B是相对于 的上游项目Project C。

\n

Project C是相对于 的下游项目Project B。

\n

生命的循环还在继续。

\n

注意：请注意，这是开源项目中相当常见的开发风格，用于创建项目的分支，修复错误或在该分支中添加功能，然后向原始项目提交补丁。

\n

另请注意，从\xe2\x80\x9c质量运动\xe2\x80\x9d和统计过程控制中得到的一个明显教训是，从源头上解决质量问题的干预措施几乎总是比重复工作来解决问题更好的投资。可以预防的。所以请贡献补丁（发送Pull requests）。

\n