为什么Github上游而主要回购是本地回购？

Question

我刚开始使用Git和Github，在推送方面，我对“上游”和“下游”这两个术语感到困惑。

我在这里读到了这个问题：Definition of "downstream" and "upstream"但是brian d foy的答案（大多数在撰写这个问题时投票）是指从回购中克隆。

我不是克隆人。我开始在一个目录中工作，并使其成为git init的存储库。我打算在我的笔记本电脑上进行处理，并将我的工作保存在Github上以防笔记本电脑出现问题。我的本地回购将是主要的回购。

为什么推送到Github的命令在-u中有git push -u origin master选项，这意味着上游。如果主要回购在我的电脑上，我不会向下游推吗？

Answer 1

这个概念没有绑定到git clone <url>命令本身（它与git init后面跟git remote add origin <url>基本上没有区别），而是绑定到每个repo在分布式版本控制中扮演的角色。这在使用DVCS时并不是绝对的，如the second answer of the question you've linked to中所述。

我想认为上游是“官方”或“普通”版本的地方，任何人最终都会咨询以获得最真实的版本。

如果其他人（或您自己在另一台计算机上）通过Github与您合作，那么Github将成为您和他们获取最新更新的常用信息的主要持有者。所以这将是你的上游。

另一方面，如果您的本地回购和Github的回购以某种方式分歧，您的版本应该被认为是最正确的，那么Github就是您的下游，并且您实际上是在向下游推送信息。但对于从Github获取信息的其他人来说，这是他们的直接上游（并且您的回购是间接上游）。

修改

关于-u|--set-upstream标志，它实际上为被推送的分支设置远程跟踪分支，因为跟踪上游是合乎逻辑的（因此您可以接收新信息），而不是下游（具有与您相同或更旧的信息）。由于从下游推送/拉取非常罕见，因此该标志的名称中包含 upstream 。此外，当您拥有分布式架构时，上游和下游的概念有时会变得不那么有意义。

对于Github案例，您可以使用分支上的远程跟踪信息来简化命令使用，即使您将其视为下游。

Answer 2

而不是谈论上游/下游，远程/本地 git repo更精确，更容易理解。

Github是我们可以托管远程仓库（或称之为上游）的地方。

本地仓库（或称之为下游）只是适用于远程仓库的工作副本。

所以你可以扭转你的理解， github实际上是主要的回购，本地回购只是工作副本。原因包括：

• github可以很好地管理版本，尤其是不止一个开发人员在这个版本上工作。
• 这是DVCS（分发版本控制系统）的正确含义，开发人员可以随时随地处理工作副本。您可以比较local version control systems and DVCS。

如果您想将本地仓库视为主（远程仓库），则不再需要github。您只需要将此repo克隆到其他目录并在工作副本上进行开发，然后提交/推送到此远程仓库。

函数git push -u origin master是将本地主分支推送到github并在本地主分支和远程主分支之间设置跟踪引用（可以使用git branch -vv来查看跟踪关系）。使用git push -u的情况是：

• 你在本地初始化一个git repo，所以git将它与远程分支区别对待。
• 你克隆了一个远程仓库，但是你在本地创建了一个newbranch，所以git不知道哪个分支被推送到了。您可以使用git push origin newbranch（在远程创建newbranch并向其推送本地newbranch）或git push -u origin newbranch（在远程创建newbranch并将本地newbranch推送到它并设置本地newbranch和远程newbranch之间的跟踪关系）。