Git 从原点拉出所有分支

我可以这样说：

git push --all origin

它会将所有分支推送到原点。但如果我这样做：

git pull --all origin

git pull --all

然后它不会从原点拉取所有分支，它只返回一个错误：

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

好的，我这样做：

git pull --all origin

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.

---

那么，我如何从源代码中提取所有分支（如Ipushall branchstoorigin by

git push--all origin

）？

git pull

首先使用

git fetch

获取所有内容，这意味着

origin

命名空间将包含来自

源代码的所有内容（请参阅）

但它将只合并到
origin/currentBranch
到
currentBranch

它不会创建其他分支

如果它从
origin
创建所有分支，您的git分支将被上游回购的潜在多个分支“污染”。

通常，您只希望将要处理的分支作为本地分支

如果您想从远程跟踪所有分支，可以参考问题“.”
中的内容，其中包含了使各种设置正常工作所需的所有项目，但可以对git有些陌生的项目进行一些背景说明

在我认为非常不幸的命名中，git有
fetch
、
push
和
pull
。听起来像是拉的方向与推的方向相反，但事实并非如此！
推送
最接近反面的东西实际上是
获取
（即使如此，它们也不是完全对称的）

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

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

当您运行
git fetch
时，您的git会联系一些远程（
origin
）并询问它有哪些分支1，以及这些标签指向什么。您可以通过运行
git ls remote
看到这一点：

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

正常的
获取
会带来所有分支，并将它们以不同的名称写入存储库。在这种情况下，
master
变成
origin/master
，
branch
变成
origin/branch

为了引入分支标签，它还引入了提交本身（如上面的
222c4dd…
），以及完成提交所需的任何其他底层对象。（这包括他们拥有的、您还没有的任何开发历史。）然后，新的远程调整分支名称（
origin/branch
）设置为直接指向该提交（
222c4dd…
）

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

同样，当我们把他们的
母版
带过来时，它就变成了
原始版/母版
。我们没有一个分支被命名为
origin/which
，因此这不可能破坏我们的分支。但是当我们把
主控
推给他们时，我们只是告诉他们将其设置为他们的
主控
。我们不会说：“将我们的
主控
推送到您的
亚历山大/主控
”。这就是为什么在推之前，我们通常必须将
主控
与他们的主控
合并或重设基础，这样当我们告诉他们“嘿，将您的
主控
设置为提交
af7c315
”时，我们确保这个新的提交ID包含了他们所有的历史记录，这样他们就不会丢失任何历史记录

这就是
git pull
的用武之地。要更新他们的
母版
，我们需要首先将他们的
母版
，使用
git fetch
，在本地副本中将其重命名为
origin/master
。然后，一旦我们与它们同步，我们就会合并或重新设置
master
和
origin/master
（现在与它们的
master
同步）。最后，当这项工作完成且效果良好时，我们可以将新的
主控
——它现在基于与
原始/主控
相匹配的
主控
——与
主控
相结合。只要这一切发生得足够快，这一切都会起作用。（如果其他人在推送<代码>方面击败我们，速度不够快，那么我们必须再次获取、合并或重新设置基址，然后再次尝试推送<代码>，重复，直到我们赢得与其他尝试推送<代码>的人的比赛）

git pull
脚本简单地自动化了获取和合并/重基部分。但它只有一个分支可以做到这一点：我们现在签出的任何分支。这是因为，在git中，
merge
和
rebase
命令只更改一个分支：
merge
合并到当前分支，而
rebase
g