git 远程更新和 fetch 之间的区别？

Question

是 git remote update 相当于 git fetch?

Answer 1

更新：更多信息！

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

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

然后我做了一个 less 搜索 --all, ，这是我在 Git 版本 1.6.6 的发行说明:

git fetch 学到了 --all 和 --multiple 选项，从多个存储库运行 fetch，以及 --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, ，但他们决定不删除它，也许是为了向后兼容现有的脚本和程序，或者可能是因为它的工作量太大并且有更高优先级的项目。

---

原始答案有更多细节

异种种族灭绝的答案 现在已经 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 获取 (1) 或 update 子命令 git 远程(1). — git-config 文档

这相当于使用

git remote update

没有指定任何要获取的远程组，也没有 remotes.default 在您的存储库配置中进行设置，并且您的遥控器都没有 remote.<name>.skipDefaultUpdate 设置为 true。

这 Git 配置的最新 1.8.3.2 文档 没有提到 remotes.default 设置，但我咨询了全能谷歌并发现了这个有用的解释 米斯拉夫·马罗尼奇:

$ 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 获取 (1) 或 update 子命令 git 远程(1).

获取指定的一组遥控器

不是获取所有遥控器，而是 fetch 和 remote update 允许您指定要获取的多个遥控器和遥控器组：

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

git fetch [<options>] <group> 允许您获取属于一个组的多个遥控器（借用另一个例子 米斯拉夫):

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

git fetch --multiple 允许您指定多个存储库和存储库组来一次获取（从 文档):

允许多个 <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 不能用于像 with 那样只获取单个遥控器 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] 不过，有。

Answer 2

是，也不是。 git remote update从所有的遥控器取出，而不是仅仅一个。

不看的代码，以查看是否remote update仅仅是一个外壳脚本（可能的）它，基本上，运行取为每个远程。 git fetch可以更加精细。