git - 从原点 pull 所有分支

Question

我可以这样说：

git push --all origin

它将把所有分支推向起源。但是，如果我这样做：

git pull --all origin

那么它不会从原点拉出所有分支，只会返回一个错误：

fatal: fetch --all does not take a repository argument

好的，我这样做：

git pull --all

购买却说：

You asked to pull from the remote '--all', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.

那么，如何从原点拉出所有分支（就像我通过 git push --all origin将所有分支推到原点一样）？

Answer 1

VonC's answer包含完成各种设置所需的所有项目，但对于git较新的内容，可以使用一些背景说明。

我认为这是一个非常不幸的命名方式，git具有fetch，push和pull。听起来pull是与push相反的方向，但事实并非如此！ push与之最相反的东西实际上是fetch（即使这样它们也不是完全对称的）。

为了正确理解所有这些，您需要知道在git中，分支名称仅是特定提交的标签，具有一个非常特殊的属性。 “常规”或“本地”分支名称（通常简称为“分支”）（如master）具有特殊的属性，当您按分支名称检出然后在存储库中进行新提交时，该分支名称会自动继续以包括您的新提交。 （并且每个新的提交都指向其“父”旧的提交，或者合并到其所有父级。）

Git还提供了“远程分支”，这（在git传统中）的名称有些误导，因为它们也存在于您的存储库中，而不是其他“远程”存储库中。这些名称以远程名称为前缀，例如origin，因此您将origin/master作为“远程分支”。同样，这些只是提交的标签。取消本地分支，在您提交时它们不会移动，但它们确实会移动。当您使用git fetch时它们会移动。

当您运行git fetch时，您的git会联系某个远程对象（origin），并询问它具有哪些branch1，以及这些标签所指向的对象。您可以通过运行git ls-remote看到此内容：

$ git ls-remote
From ssh://[redacted]
d1574b852963482d4b482992ad6343691082412f    HEAD
222c4dd303570d096f0346c3cd1dff6ea2c84f83    refs/heads/branch
d1574b852963482d4b482992ad6343691082412f    refs/heads/master
d41117433d7b4431a188c0eddec878646bf399c3    refs/tags/tag-foo

普通的 fetch会带来所有分支，并以不同的名称将其写入您的存储库。在这种情况下， master变为 origin/master，而 branch变为 origin/branch .2

要带来一个分支标签，它还带来了提交本身（例如上面的 222c4dd...），以及带来完成提交所需的任何其他基础对象。 （这包括他们拥有的，您尚未拥有的任何开发历史记录。）然后，将新的，远程调整的分支名称（ origin/branch）设置为直接指向该提交（ 222c4dd...）。

因此，如前所述， git fetch会覆盖所有分支，就像 git push --all推送所有分支一样。 fetch不执行的操作是将所有这些更新合并到您自己的本地分支中。这也是 fetch和 push不再互为镜像的地方：当您 push到远程的分支时，不会自动重命名。3

同样，当我们提出他们的 master时，它变为 origin/master。我们的分支都没有被命名为 origin/whatever，因此这不可能破坏我们的分支。但是，当我们将 master推送给他们时，我们只是告诉他们将其设置为他们的 master。我们不会说：“将我们的 master推送到您的 alexander/master”。4这就是为什么在我们推送之前，我们通常必须将我们的 master合并或重新设置为它们的基础，以便当我们告诉他们时”嘿，将您的 master设置为提交 af7c315”，我们确保此新的提交ID包含了他们拥有的所有历史记录，这样他们就不会丢失任何历史记录。

这是 git pull的来源。要更新其 master，我们需要首先使用 master带来他们的 git fetch，这将在我们的本地副本中将其重命名为 origin/master。然后，一旦我们与它们同步，就可以合并或重新设置 master和 origin/master（现在与它们的 master同步）。最后，当完成并取得好效果时，我们可以将新的 master（现在基于/与匹配其 origin/master的 master合并）推到其 master。只要所有这些事情发生得足够快，这些都行得通。 （如果速度不够快（如果有人将我们击败了 push，那么我们就必须再次获取，重新合并或变基，然后再次尝试 ，重复直到我们也赢得了与其他人的比赛）尝试 push。）

push脚本仅使提取和合并/变基部分自动化。但这仅用一个分支来完成：我们现在已经签出的任何分支。这是因为，在git中， git pull和 merge命令仅更改一个分支： rebase合并到当前分支中，并且 merge通常重新设置当前分支的基础。 （如果您告诉 rebase重新建立其他分支的基础，它将首先将其签出。）

如果要合并或变基多个分支，则必须一次签出一个。 （使用 git rebase稍微容易些，因为 rebase是从 git rebase origin/master master开始的（因此它是内置在命令中的，但您仍在执行 git checkout master。）幸运的是， git checkout将更新所有远程分支。一次，因此您只需要一个 git fetch origin。

Git通常假定，除非您计划更改分支中的某些内容或将其冻结在特定的提交中，否则您不会签出自己的版本。也就是说，您不这样做：

$ git checkout --track feature origin/feature

除非您打算对此做某事。因此，除非您已经在分支 git fetch上，否则不会调用将其变基或合并的方法。

因为 feature会进行初始签出，通常是 git clone签出，而人们通常会使用功能分支，所以通常会先处理要使用的一个分支（ master），而不要处理一个本地分支不需要（ feature）。但是，只要离开分支直到 master直到您确实需要它，这是没有错的。或者在完成其他分支的 origin/master之后，甚至可以删除它：

$ git checkout branch       # newer gits do --track automatically
Branch branch set up to track remote branch branch from origin.
Switched to a new branch 'branch'
$ git branch -d master
warning: deleting branch 'master' that has been merged to
         'refs/remotes/origin/master', but not yet merged to HEAD.
Deleted branch master (was d1574b8).
$ 

（警告很烦人，但无害）。



1 git checkout还可以看到标签和其他参考，您可以指示它带来更多内容。上面的示例显示了一个标签，加上 fetch。添加 HEAD或更改 --tags行，可以将标签移到上方。 fetch =参考是特殊的，并且git在克隆操作中对待 HEAD的方式中存在一个长期存在的细微错误，这通常并不重要，并且需要更改协议以进行修复，因此没有人修复它。

2更精确地说， HEAD映射到 refs/heads/*，其中复制了 refs/remotes/origin/*部分。因此，如果遥控器上有 *，则会得到 refs/heads/this/that。这就是 refs/remotes/origin/this/that文件中 fetch =定义下的 remote行所针对的：它告诉 .git/config如何重新映射远程引用。这也是为什么我说“正常”提取：您可以配置它或使用选项运行它以使其行为有所不同。

git新手可能会想知道为什么要重命名。好吧，假设您首先抓住他们的 fetch并创建一个新的本地 master分支，以便可以进行更改。然后，您需要进行一些更改，并使用 master和 git add创建至少一个新提交。同时，他们（无论“他们”是谁）也改变了事情并做出了新的承诺。您想看看他们做了什么，所以您 git commit他们的新东西。如果那淹没了您的 git fetch，您的工作将会怎样？幸运的是，git以不同的名称带来了他们的新作品： master。您的 origin/master保持不变，跟踪您的新提交。

3至少不是默认情况下。与大多数git一样，您可以使用命令行标志和配置条目来更改此行为。

4实际上，正如脚注3所述，我们可以完全做到这一点，在某些设置中，您甚至可能想要这样做。但这通常不是人们在共享存储库中使用git的方式。