Question

在开始之前，我知道git pull和git fetch 之间的区别。

但是，我想一次拉出每个分支，并且我了解到存在一个命令git pull --all，但是它并没有达到目的，因为它获取所有分支，但只合并了我自己的那个分支使用它的远程功能（其他this等stackoverflow帖子向我保证了这一点。）

man git-pull上的文档引用了git fetch命令，并且在--all部分中说

   Options related to fetching
   --all
       Fetch all remotes.

那么，我的问题是热的。

由于git pull --all的名称具有误导性，因此存在意义吗？

由于man git-fetch与git pull --all不同，以一种也会引起误解的方式引用git fetch --all是否有意义？

（我知道这个问题听起来似乎主要是基于意见的问题，但是也许您可以从中了解到我现在还没有的这些git命令。其他人可能也没有。

（ em>）

Answer 1

这可能是因为git pull必然涉及git fetch操作。 git fetch有一个--all标志，因此我们在--all上也有一个git pull标志，因此git pull可以将相同的标志传递给{{1 }}（这绝对是必须要做的）。

是的，名称可能有所不同，并且可能避免混淆，但是例如，让git fetch带有一个名为git pull的标志同样令人困惑，该标志最终像--all-remotes的{{1}}选项。也许如果他们也将--all上的fetch选项也更改为--all的话，它就会奏效-但您可能会建议对API进行重大更改，以使清晰度有所改善，这通常是个坏主意。

旁注：据我所知，没有内置命令可以立即更新所有分支。 Hub拥有sync，将做到这一点，但除此之外，我的研究似乎表明，最好的选择是使用自己的别名或函数来检出所有分支一对一。

Answer 2

原始的git pull是一个shell脚本，它：

运行了两个Git命令：git fetch，然后是第二个，通常是git merge； ¹
将特定选项视为自己的选项，并将其从参数列表中删除；
将特殊选项识别为传递给 second 命令的选项，并将它们也从参数列表中删除，直到运行第二条命令为止；和
没有真正看，只是将剩下的一切传递给了第一个Git命令git fetch。

这样，如果要运行git fetch --all，然后再运行pull的第二个Git命令，则可以运行git pull --all。这几乎很少有用，而对第二条命令来说根本没有用，对第二条命令来说根本没有用，实际上并没有什么意义。脚本很愚蠢，只是将所有内容传递了出去。

Git作者努力保持向后兼容性。因此，如果您可以在之前 git pull做些毫无意义的事情以使其在Windows上快速运行，则重写必须支持您在之前可以做的一切。。因此，即使这样做没有任何意义，它也必须接受并继续使用--all选项。

¹另一个明显的是git rebase。但是，有很多棘手的情况，例如在新的，否则为空的存储库中运行git pull时，因此在极少数情况下，git pull必须使用另一个不同的第二条命令。脚本至少一次出错了，而我曾经以这种方式破坏了几天的工作。如果可以避免，我将不再使用git pull。

（在空存储库的情况下，我们只想基于获取的结果创建当前分支。没有要合并或变基的内容，因此我们不能使用git merge或{{1} }。但是如果有未跟踪的文件该怎么办呢？原始的git rebase脚本将其销毁了。）

存在“ git pull --all”的原因是什么？

2 个答案: