git remote update相当于git fetch? _
问问题
88810 次
2 回答
143
是和不是。git remote update从所有遥控器中获取，而不仅仅是一个。
无需查看代码以查看是否remote update只是一个 shell 脚本（可能），它基本上为每个遥控器运行 fetch。git fetch可以更细化。
于 2009-12-06T20:29:21.927 回答
127
更新：更多信息！
我应该从一开始就这样做：我在 Git 的 Git 存储库中抓取了 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 updatenorremote 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在您的 repo 配置中设置，而且您的所有遥控器都没有remote.<name>.skipDefaultUpdate设置为 true。
Git 配置的当前 1.8.3.2 文档没有提及remotes.default设置，但我咨询了全能的 Google 并从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设置，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命令的解释没有说明指定多个组和远程参数，只是它
Fetch[es] 更新存储库中由
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）并不是唯一的。我注意到 and 有类似的情况git rebase --onto，git cherry-pick因为两者都可以进行一系列提交来修补新的基本提交。
我猜随着 Git 多年来的发展，某些功能（不可避免地？）被重复了，有时可能是为了方便最终用户（例如，将范围传递给cherry-pick，而不是一遍又一遍地传递单个提交更简单选择一个范围）。显然cherry-pick并不总是接受一系列提交，如v1.7.2 发行说明中所述：
git cherry-pick学会了选择一系列提交（例如cherry-pick A..Bandcherry-pick --stdin），所以也学会了git revert；但是，这些不支持更好的排序控制rebase [-i]。
于 2013-07-07T12:06:32.587 回答