上游(与之相关)跟踪

对于GIT工具套件，术语上游也有一些明确的含义，特别是与跟踪相关的含义

例如:

$git rev-list——count——left-right "@{upstream}" 4 > 12 将打印当前工作分支后面(左)和前面(右)的提交数(最后的缓存值)，相对于当前跟踪此本地分支的远程分支(如果有)。否则将打印错误消息: >错误:没有发现上游分支

正如已经说过的，你可能有一个本地存储库的任何数量的远程，例如，如果你从github分叉一个存储库，然后发出一个“拉请求”，你肯定至少有两个:起源(你在github上的分叉回购)和上游(你从github上分叉的回购)。这些只是可以互换的名字，只有“git@..”。' url标识它们。

你的。git/configreads: (远程“起源”) Fetch = +refs/heads/*:refs/remotes/origin/* Url = git@github.com:myusername/reponame.git (远程“上游”) Fetch = +refs/heads/*:refs/remotes/upstream/* Url = git@github.com:authorname/reponame.git

另一方面，@{upstream}对于GIT的意义是唯一的:

它是'said remote'上的'分支'(如果有的话)，它跟踪'本地存储库'上的'当前分支'。 它是你每次调用纯git fetch/git pull时的fetch/pull分支，不带参数。

假设要将远程分支origin/master设置为已签出的本地主分支的跟踪分支。问题是:

$ git branch --set-upstream master origin/master > Branch master set up to track remote branch master from origin. This adds 2 parameters in .git/config : [branch "master"] remote = origin merge = refs/heads/master now try (provided 'upstream' remote has a 'dev' branch) $ git branch --set-upstream master upstream/dev > Branch master set up to track remote branch dev from upstream. .git/config now reads: [branch "master"] remote = upstream merge = refs/heads/dev git-push(1) Manual Page : -u --set-upstream For every branch that is up to date or successfully pushed, add upstream (tracking) reference, used by argument-less git-pull(1) and other commands. For more information, see branch.<name>.merge in git-config(1). git-config(1) Manual Page : branch.<name>.merge Defines, together with branch.<name>.remote, the upstream branch for the given branch. It tells git fetch/git pull/git rebase which branch to merge and can also affect git push (see push.default). \ (...) branch.<name>.remote When in branch < name >, it tells git fetch and git push which remote to fetch from/push to. It defaults to origin if no remote is configured. origin is also used if you are not on any branch.

上游和推进(明白了)

看看git-config(1)手册页

Git配置——global push.default upstream Git配置——global push.default跟踪(已弃用) 这是为了防止意外地推到您还没有准备好推的分支。

以河流为例，我们可以沿着资源逆流而上，直到找到源头(溪流或河流的源头)。

继续河的比喻，下游是河中水流动的方向。下坡。

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

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

我的叉子上的叉子顺流而下。

例如时间!

假设项目B衍生出项目A，项目C衍生出项目B。

那么项目A就是上游项目。

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

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

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

生命的循环还在继续。

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

还要注意，从“质量运动”和统计过程控制中得到的一个明显教训是，从源头解决质量问题的干预措施几乎总是比重复解决可以预防的问题更好的投资。所以请贡献补丁(发送Pull请求)。

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

当您进行更改时，您通常希望将它们发送回“上游”，以便它们进入存储库，以便从同一源提取的每个人都使用相同的更改。这主要是一个社会问题，即每个人如何协调他们的工作，而不是源代码控制的技术需求。您希望将更改放到主项目中，这样就不会跟踪不同的开发线。

有时您会读到包或发布管理人员(人，而不是工具)谈论向“上游”提交更改。这通常意味着他们必须调整原始源代码，以便为他们的系统创建一个包。他们不想继续做这些更改，所以如果他们将这些更改“上游”发送到原始源代码，他们就不应该在下一个版本中处理相同的问题。

这是一个非正式的术语。

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

一般来说，上游是克隆的地方(源)。下游是将您的工作与其他工作集成在一起的任何项目。

这些术语并不局限于Git存储库。

例如，Ubuntu是Debian的衍生版本，所以Debian是Ubuntu的上游。

上游(与之相关)跟踪

对于GIT工具套件，术语上游也有一些明确的含义，特别是与跟踪相关的含义

例如:

$git rev-list——count——left-right "@{upstream}" 4 > 12 将打印当前工作分支后面(左)和前面(右)的提交数(最后的缓存值)，相对于当前跟踪此本地分支的远程分支(如果有)。否则将打印错误消息: >错误:没有发现上游分支

正如已经说过的，你可能有一个本地存储库的任何数量的远程，例如，如果你从github分叉一个存储库，然后发出一个“拉请求”，你肯定至少有两个:起源(你在github上的分叉回购)和上游(你从github上分叉的回购)。这些只是可以互换的名字，只有“git@..”。' url标识它们。

你的。git/configreads: (远程“起源”) Fetch = +refs/heads/*:refs/remotes/origin/* Url = git@github.com:myusername/reponame.git (远程“上游”) Fetch = +refs/heads/*:refs/remotes/upstream/* Url = git@github.com:authorname/reponame.git

另一方面，@{upstream}对于GIT的意义是唯一的:

它是'said remote'上的'分支'(如果有的话)，它跟踪'本地存储库'上的'当前分支'。 它是你每次调用纯git fetch/git pull时的fetch/pull分支，不带参数。

假设要将远程分支origin/master设置为已签出的本地主分支的跟踪分支。问题是:

$ git branch --set-upstream master origin/master > Branch master set up to track remote branch master from origin. This adds 2 parameters in .git/config : [branch "master"] remote = origin merge = refs/heads/master now try (provided 'upstream' remote has a 'dev' branch) $ git branch --set-upstream master upstream/dev > Branch master set up to track remote branch dev from upstream. .git/config now reads: [branch "master"] remote = upstream merge = refs/heads/dev git-push(1) Manual Page : -u --set-upstream For every branch that is up to date or successfully pushed, add upstream (tracking) reference, used by argument-less git-pull(1) and other commands. For more information, see branch.<name>.merge in git-config(1). git-config(1) Manual Page : branch.<name>.merge Defines, together with branch.<name>.remote, the upstream branch for the given branch. It tells git fetch/git pull/git rebase which branch to merge and can also affect git push (see push.default). \ (...) branch.<name>.remote When in branch < name >, it tells git fetch and git push which remote to fetch from/push to. It defaults to origin if no remote is configured. origin is also used if you are not on any branch.

上游和推进(明白了)

看看git-config(1)手册页

Git配置——global push.default upstream Git配置——global push.default跟踪(已弃用) 这是为了防止意外地推到您还没有准备好推的分支。

上游称为有害

唉，“上游”还有另一种用法，这里的其他答案都没有提到，即指在一个repo中提交的父子关系。在Pro Git一书中，Scott Chacon特别容易出现这种情况，结果很不幸。不要模仿这种说话方式。

例如，他说合并导致了快进，这是因为

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

He wants to say that commit B is the only child of the only child of ... of the only child of commit A, so to merge B into A it is sufficient to move the ref A to point to commit B. Why this direction should be called "upstream" rather than "downstream", or why the geometry of such a pure straight-line graph should be described "directly upstream", is completely unclear and probably arbitrary. (The man page for git-merge does a far better job of explaining this relationship when it says that "the current branch head is an ancestor of the named commit." That is the sort of thing Chacon should have said.)

事实上，Chacon自己在后面提到重写已删除提交的所有子提交时，似乎使用了“下游”来表达完全相同的意思:

必须重写从6df76开始的所有提交，才能完全删除 这个文件来自你的Git历史记录

基本上，在提到提交历史时，他似乎不清楚“上游”和“下游”是什么意思。因此，这种用法是非正式的，不鼓励使用，因为它会令人困惑。

很明显，每个commit(除了一个)都至少有一个父结点，因此父结点的父结点就是祖先;而在另一个方向上，承诺有子女和后代。这是公认的术语，并且明确地描述了图的方向性，所以当您想要描述在repo的图几何中提交如何相互关联时，这就是谈论的方式。在这种情况下，不要随意使用“上游”或“下游”。

[Additional note: I've been thinking about the relationship between the first Chacon sentence I cite above and the git-merge man page, and it occurs to me that the former may be based on a misunderstanding of the latter. The man page does go on to describe a situation where the use of "upstream" is legitimate: fast-forwarding often happens when "you are tracking an upstream repository, you have committed no local changes, and now you want to update to a newer upstream revision." So perhaps Chacon used "upstream" because he saw it here in the man page. But in the man page there is a remote repository; there is no remote repository in Chacon's cited example of fast-forwarding, just a couple of locally created branches.]