git fetch + git merge原点/主节点vs git pull原点/主节点 [英] git fetch + git merge origin/master vs git pull origin/master

问题描述

我认为git pull就像git fetch + git merge一样.在branchA中，我总是先进行git fetch，然后进行git merge origin/master.但是今天，在一个branchA中，我尝试了git pull origin/master，但没有用，但是做了git pull origin master了.有什么想法吗?

I thought git pull was like a git fetch + git merge. Being in branchA, I always do a git fetch and then a git merge origin/master. But today, being in a branchA, I tried git pull origin/master and it didn't work but doing a git pull origin master worked. Any thoughts?

额外的问题是，如果更新的原始版本/母版和在线版本的母版相同，为什么还要麻烦拥有原始版本/母版，那么始终使用始终更新，发布的在线版本会更方便吗?我们从负担到总是被git抓取?

Extra question, if an updated origin/master and the online version of master are the same, why bother to have origin/master, wouldn't it be more convenient to always work with the online version that is always updated, releasing us from the burden to alway be git fetching?

推荐答案

我认为git pull就像git fetch + git merge.

I thought git pull was like a git fetch + git merge.

是的.但是，与 git pull 一起使用的语法与几乎所有其他Git命令一起使用的语法不匹配.这是由于历史原因: git pull 在Git 1.5之前和1.6后的Git版本之间进行了许多改进.(请注意，Git现在的版本为2.26，所以这确实是古老的历史，可以追溯到2005年左右.人们今天仍然使用的最旧的Git版本是1.7版，但是当您运行git pull ，您正回到石头时代之前的恐龙Git 1.5时代.)

It is. However, the syntax one uses with git pull does not match the syntax one uses with pretty much every other Git command. This is due to history: git pull predates a number of improvements made in Git between pre-1.5 and post-1.6 Git versions. (Note that Git is now at version 2.26, so this is truly ancient history, dating back to 2005 or so. The oldest versions of Git that people still seem to use today are in the version 1.7 range—but when you run git pull, you're harking back to the pre-stone-age, dinosaur Git 1.5 era.)

[但是]我尝试了 git pull origin/master ，但它不起作用[而] git pull origin master/起作用

[but] I tried git pull origin/master and it didn't work [while] git pull origin master worked

那是因为这是 git pull 的特殊语法.

That is because this is the special syntax just for git pull.

请仔细阅读 git pull 文档，以了解例外情况(其中有很多)，但是一般来说，您传递给 git pull ， git pull 的大多数参数都传递给 git fetch .就像您不会运行:

Read the git pull documentation carefully for exceptions (of which there are plenty), but in general, most of the arguments you pass to git pull, git pull passes to git fetch. Just as you would not run:

git fetch origin/master      # wrong

你不能跑步

git pull origin/master       # also wrong: this runs git fetch origin/master

但是，您可以运行:

git fetch origin master

此处 origin 是 remote ，而 master 是 refspec (请参阅

Here origin is a remote and master is a refspec (see the git fetch documentation for more about remotes and refspecs). This specifically limits your git fetch operation to fetch only commits new-to-you that are on their master, so as to update only your origin/master.¹

提取完成后， pull 将对某些分支头提交集运行 merge ，或者，如果您指定了 rebase ，. ² 此处的一般想法(可以追溯到我提到的Git-1.6之前的历史)是，从其他Git提取了一些提交之后，您现在希望将这些提交合并到您的当前分支.

After the fetch is complete, pull runs merge, or if you so specify, rebase, on some set of branch-head commits.² The general idea here—which goes back to that pre-Git-1.6 history I mentioned—is that, having fetched some commit(s) from some other Git, you now wish to incorporate those commits into your current branch.

有一段时间，在Git早期，整个 remote 的概念都不存在，因此没有远程跟踪名称:没有 origin 根本没有，因此没有 origin/master .因此，重要的是要立即合并他们的提交，以免Git运行垃圾回收过程并删除您获得的新提交.

There was a time, in early Git, when the entire concept of remote did not exist, and hence there were no remote-tracking names: there was no origin at all, hence no origin/master. It was therefore important to incorporate their commits immediately, lest your Git run a garbage collection pass and remove the new commits you obtained.

在1.6后的时代(即大约2006年以来)，收集提交并让它们坐在那里一段时间是很安全的，当您仔细查看它们时，请考虑一下它们，甚至一会儿完全忽略它们.远程名称 origin 引入了 remote-tracking 名称，例如 origin/master ，可无限期保留这些提交.不再需要疯狂地将这些提交推到您自己的 分支之一中，以防止它们被删除.

In the post-1.6 era—i.e., since 2006 or so—it's been safe to collect the commits and let them sit there for a while, while you look them over, think about them, or even ignore them entirely for a while. The remote name origin introduced the remote-tracking names, such as origin/master, which retains those commits indefinitely. There is no longer any need for a mad rush of shoving those commits into one of your own branches, in order to prevent them from being removed.

最重要的是:如果您方便使用 git pull ，请使用它.如果没有，那就不要.请记住，要使用的参数(如果使用了参数)是唯一的.这只是 git fetch 的组合，再加上直接的第二条命令，可将某些已提取的提交合并到当前分支.在大多数情况下，我都很方便地找到:我想先检查所获取的提交.如果您不使用 git pull ，则会使用远程跟踪名称(例如 origin/master )来命名传入的提交，但是如果您使用 git pull ，您不能在 git pull 命令本身中使用这些名称，因为它与古代不存在这些名称的时代兼容

The bottom line is: If you find git pull convenient, use it. If not, don't. Remember that the arguments you'll use, if you use arguments, are unique to it. It's just a combination of git fetch, plus an immediate second command to incorporate some fetched commits into the current branch. I find this in-convenient, most of the time: I like to inspect the fetched commits first. If you don't use git pull, you'll name the incoming commits with remote-tracking names like origin/master, but if you do use git pull, you can't use these names in the git pull command itself, because it is being compatible with ancient times when these names did not exist.

¹ 这种 git fetch 会在任何现代Git中更新您的 origin/master ，但在1.8.4之前的Git版本中，它将保留 origin/master 不变.

¹This kind of git fetch will update your origin/master in any modern Git, but in Git versions before 1.8.4, it will leave origin/master un-updated.

² 被选作合并或变基参数的提交是那些您在命令行上专门命名的引用(如果您已命名)中的提交.否则，选择作为参数的(单个)提交是与当前分支的 upstream 设置相对应的提交.

²The commits chosen as arguments to merge or rebase are those from references that you specifically named on the command line, if you named any. Otherwise, the (single) commit chosen as an argument is the one corresponding to the upstream setting of the current branch.

在某些特殊情况下， git pull 会执行除merge或rebase以外的其他操作作为第二个命令.这些特殊情况中最有趣的是拉入一个完全空的存储库:在这里， git merge 和 git rebase 都不会做任何事情，因此 git pull 实际上只是运行 git checkout .这种特殊情况显然在任何给定的存储库中只会发生一次.

In some corner cases, git pull runs something other than merge or rebase as its second command. The most interesting of these special cases is pulling into a completely empty repository: here, neither git merge nor git rebase will do anything, so git pull essentially just runs git checkout instead. This one special case obviously happens only once in any given repository.

这篇关于git fetch + git merge原点/主节点vs git pull原点/主节点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！