git remote update 和 fetch 的区别？

Question

git remote update 是否等同于 git fetch？

Answer 1

更新：更多信息！

我应该从一开始就这样做：我在 Git 的 Git 存储库中搜索了 Git 发行说明（太元了！）

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

然后我在less 搜索--all，这就是我在release notes for Git version 1.6.6 下找到的：

git fetch 学习了 --all 和 --multiple 选项，以从许多存储库中运行 fetch，以及 --prune 选项以删除过时的远程跟踪分支。这些使git remote update 和git remote prune 的必要性降低（但没有计划删除remote update 和remote prune）。

直到December 23rd, 2009 1.6.6 版才发布，原始发帖人于 2009 年 12 月 6 日提出了他的问题。

从发行说明中可以看出，Git 的作者意识到 git remote update 命令功能在某种程度上被 git fetch 复制，但他们决定不删除它，也许是为了向后兼容使用现有的脚本和程序，或者可能是因为工作量太大而且有更高优先级的项目。

---

包含更多细节的原始答案

xenoterracide's answer 现在 3.5 岁了，从那时起 Git 经历了几个版本（在撰写本文时它已经从 v1.6.5.5 到 v1.8.3.2），并查看 当前文档为git remote update 和git fetch，看起来他们都可以执行从多个遥控器获取新提交的基本相同的功能 strong>，给定正确的选项和参数。

获取所有遥控器

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

git fetch --all

这将从您配置的所有遥控器中获取，假设您没有为它们设置remote.<name>.skipFetchAll：

如果为 true，则在使用 git-fetch(1) 或 git-remote(1) 的 update 子命令进行更新时，将默认跳过此远程。 — git-config documentation

这相当于使用

git remote update

没有指定要获取的任何远程组，也没有在您的 repo 配置中设置remotes.default，并且您的所有远程都没有将remote.<name>.skipDefaultUpdate 设置为true。

current 1.8.3.2 documentation for Git's configuration 没有提到remotes.default 设置，但我咨询了全能的谷歌并从Mislav Marohnić 找到了这个有用的解释：

$ 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的设置，the Git docs这样解释：

如果为 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 允许您指定多个存储库和存储库组以一次获取（来自the docs）：

允许指定多个 <repository> 和 <group> 参数。不能指定<refspec>s。

git remote update 文档中的歧义

synopsis for 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 的文档不清楚是否可以获取除单个组之外的任何内容strong> 的遥控器。

总结

正如我所解释的，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 release notes 中所述：

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

Answer 2

是和不是。 git remote update 从所有远程获取，而不仅仅是一个。

如果不查看代码以查看 remote update 是否只是一个 shell 脚本（可能），它基本上会为每个遥控器运行 fetch。 git fetch 可以更细化。