git remote update和fetch之间的区别？

是git remote update相当于git fetch？

更新：更多信息！

我应该从一开始就应该做到这一点：我在Git的Git存储库中添加了Git发行说明（所以meta！）

grep --color=always -R -C30 fetch Documentation/RelNotes/* | less

然后我进行了less搜索--all，这是我在Git版本1.6.6的发行说明中找到的内容：

git fetch学习--all和--multiple选择，可以从许多存储库中获取数据，--prune选择可以删除已过时的远程跟踪分支。这些使得git remote update和git remote prune不必要的（尽管没有计划删除remote update或remote prune）。

版本1.6.6直到2009年12月23日才发布，原始海报在2009年12月6日问了他一个问题。

因此，从发行说明中您可以看到，Git的作者意识到git remote update命令功能被某种程度地复制了git fetch，但是他们决定不删除它，可能是为了与现有脚本和程序向后兼容，或者可能是因为这是太多的工作，还有更高优先级的项目。

原始答案有更多详细信息

xenoterracide的答案，现在为3.5岁，从那以后，Git有过好几个版本了（它已经从去v1.6.5.5到v1.8.3.2写这篇文章的），并期待在当前的文档git remote update和git fetch，它看起来就像它们都可以执行基本相同的功能一样，只要提供正确的选项和参数，就可以从多个远程站点获取新的提交。

获取所有遥控器

获取多个遥控器的一种方法是使用--all标志：

git fetch --all

假设您没有remote.<name>.skipFetchAll为其设置所有设置，则将从所有已配置的遥控器获取：

如果为true，则在使用git-fetch（1）或git-remote（1）的update子命令进行更新时，默认情况下将跳过此远程控制器。— git-config文档

这相当于使用

git remote update

而不指定要获取的任何远程组，也没有remotes.default在回购配置中进行设置，并且没有任何远程remote.<name>.skipDefaultUpdate设置为true。

在当前的1.8.3.2文档Git的配置中没有提及remotes.default的设置，但我咨询全能谷歌一下，发现从这个有用的解释MislavMarohnić：

$ git config remotes.default 'origin mislav staging'
$ git remote update

# fetches remotes "origin", "mislav", and "staging"

您可以定义该remote update命令要获取的遥控器的默认列表。这些可以远离您的队友，开源项目的受信任社区成员或类似的人。

因此，大概是，如果您已remotes.default设置好了，并且其中没有列出所有的遥控器，则git remote update不会获取您的存储库已“意识到”的所有遥控器。

至于remote.<name>.skipDefaultUpdate设置，Git文档对此进行了解释：

如果为true，则在使用git-fetch（1）或git-remote（1）的update子命令进行更新时，默认情况下将跳过此远程控制器。

获取指定的远程组

而不是获取所有远程，而是通过两者fetch，remote update您可以指定多个远程和要获取的一组远程：

git fetch [<options>] <group>
git fetch --multiple [<options>] [(<repository> | <group>)…]

git fetch [<options>] <group>允许您获取属于组的多个远程服务器（从Mislav借用另一个示例）：

$ git config remotes.mygroup 'remote1 remote2 ...'
$ git fetch mygroup

git fetch --multiple允许您指定几个存储库和存储库组以一次（从docs）获取：

允许指定多个<repository>和<group>参数。没有<refspec>s可以指定。

git remote update文档中的歧义

的摘要git remote update指定命令语法如下：

git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)…]

注意最后一部分[(<group> | <remote>)…]吗？尾部的点...表示您可以使用该命令指定多个组和远程对象，这意味着它的行为与git fetch --multiple...的行为相同……请参阅两者的语法是如此相似？

但是，在同一文档中，该update命令的说明没有涉及指定多个组和远程参数，只是

根据定义，在存储库中获取一组命名的远程更新remotes.<group>。

因此，尚不清楚在指定多个单独的远程对象和多个远程组方面是否git remote update可以相同地工作git fetch --multiple。

取得一个遥控器

最后，每个人都知道获取单个远程对象的简单情况：

git fetch <remote>

您可能还可以使用

git remote update <remote>

可以做同样的事情，但是正如我在上一节中提到的，的文档git remote update尚不清楚是否可以使用该命令来获取除单个远程组以外的任何东西。

包起来

正如我已经解释过的，git fetch并且git remote update在从多个远程站点进行获取方面，其行为类似。它们具有相似的语法和参数，尽管它们git fetch较短，所以人们可能会发现它更易于键入和使用。

在某些情况下，git remote update可能无法像使用一样仅获取单个遥控器git fetch，但是正如我已经指出的那样，文档并没有明确说明这一点。

在旁边

在GIT中瓷器的命令，通过例举之间的功能的复制git fetch和git remote update上面，不是唯一的。我注意到与git rebase --onto和相似的情况git cherry-pick，因为两者都可能需要一定范围的提交才能修补到新的基本提交上。

我猜想随着Git多年来的发展，某些功能被（不可避免地？）复制了，也许有时是为了方便最终用户（例如，将范围传递给cherry-pick，而不是一遍又一遍地传递一次提交更简单）。选择范围）。显然cherry-pick，并不总是接受一定范围的提交，如v1.7.2发行说明中所述：

git cherry-pick学会了选择一系列提交（例如cherry-pick A..B和cherry-pick --stdin），也是如此git revert；但是，这些不支持更好的排序控制rebase [-i]。

是的，没有。git remote update从所有遥控器获取信息，而不仅仅是一个。

无需查看代码即可查看它remote update是否仅仅是一个shell脚本（可能），基本上，它会为每个远程服务器运行fetch。git fetch可以更加细化。