我认为git pull就像git fetch + git merge一样。在branchA中，我总是执行git fetch，然后执行git merge origin / master。但是今天，在一个branchA中，我尝试了git pull origin / master，但没有用，但是做了git pull origin master了。有什么想法吗？
额外的问题，如果更新的原始版本/母版与在线版本的母版相同，为什么还要麻烦拥有原始版本/母版，始终使用始终更新，发布的在线版本会更方便吗？我们从负担到总是被git抓取？
答案 0 :(得分：2)
我认为git pull就像git fetch + git merge。
是的。但是，与git pull一起使用的语法与几乎所有其他Git命令一起使用的语法不匹配。这是由于历史原因：git pull早于Git 1.5之前和1.6后的Git版本之间的许多改进。 （请注意，Git现在的版本为2.26，所以这确实是古老的历史，可以追溯到2005年左右。人们今天仍然使用的最旧的Git版本是1.7版，但是当您运行{{1 }}，您正回到石头时代之前的恐龙Git 1.5时代。）
[但是]我尝试了
git pull，但在git pull origin/master起作用时却没有起作用
这是因为这是git pull origin master的特殊语法。
请仔细阅读the git pull documentation中的异常（其中有很多），但通常，您传递给git pull的大多数参数，git pull都传递给git pull。就像您不会运行：
git fetch你不能跑步
git fetch origin/master # wrong
但是，您可以运行：
git pull origin/master # also wrong: this runs git fetch origin/master
这里git fetch origin master
是远程，而origin是 refspec （有关远程控制器和refspec的更多信息，请参见the git fetch documentation）。这特别限制了您的master操作，以仅提取其git fetch上的新用户，从而仅更新{em> 您的master。 > 1
提取完成后，origin/master在一组分支头提交上运行pull，或者如果您指定merge，则在某些分支头落实上运行。 2 这里的总体想法可以追溯到我提到的Git 1.6之前的历史，它是从其他Git提取了一些提交之后，您现在希望将这些提交纳入 当前分支。
有一段时间，在Git早期，整个 remote 的概念都不存在，因此没有远程跟踪名称：根本没有rebase，因此没有origin。因此，重要的是要立即合并他们的提交，以免Git运行垃圾回收过程并删除您获得的新提交。
在1.6以后的时代（即大约2006年以来），收集提交并让它们坐在那里一段时间是很安全的，当您仔细查看它们时，请考虑一下它们，甚至一会儿完全忽略它们。 远程名称origin/master引入了远程跟踪名称，例如origin，可以无限期保留这些提交。不再需要疯狂地将这些提交推入您自己的 分支之一，以防止它们被删除。
最重要的是：如果您觉得origin/master方便，请使用它。如果没有，那就不要。请记住，要使用的参数（如果使用参数）是它唯一的。这只是git pull的组合，加上立即的第二条命令将一些提取的提交合并到 current中分支。在大多数情况下，我都很方便地找到：我想先检查所获取的提交。 如果您不使用git fetch，则将使用远程跟踪名称来命名传入的提交，例如git pull，但是如果您使用origin/master，则不能在git pull命令本身中使用这些名称，因为它与不存在这些名称的远古时代兼容。
1 这种git pull会在任何现代Git中更新您的git fetch，但是在1.8.4之前的Git版本中，它将origin/master取消-更新。
2 被选作合并或变基参数的提交是那些您在命令行上专门命名的引用（如果已命名）中的提交。否则，选择作为参数的（单个）提交是与当前分支的 upstream 设置相对应的提交。
在某些特殊情况下，origin/master将运行不是合并或变基的其他命令。这些特殊情况中最有趣的是进入一个完全空的存储库：在这里，git pull和git merge都不会做任何事情，因此git rebase实际上只是运行git pull。这种特殊情况显然在任何给定的存储库中只会发生一次。