我以为git pull就像git fetch + git merge。在branchA中，我总是执行git fetch，然后进行git merge origin / master。但是今天，在一个branchA中，我尝试了git pull origin / master，但是没有用，但是做了git pull origin master了。有什么想法吗？
额外的问题，如果更新的原始版本/母版和在线版本的母版相同，为什么还要麻烦拥有原始版本/母版，总是使用始终更新的在线版本会更方便，将我们发布从负担到总是被git抓取？
我以为git pull就像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时代。）
[[但是]我尝试了
git pull origin/master，但在[git pull origin master工作时]不起作用
这是因为这是git pull的特殊语法。
仔细阅读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
是remote，而origin是refspec（有关遥控器和refspec的更多信息，请参见master）。这特别限制了您的the git fetch documentation操作，以仅获取其git fetch上的新提交内容，从而更新[[only您的git fetch。1
master在一组分支头提交上运行origin/master，或者如果您指定，则在某些分支头落实上运行。[C2]我提到的Git-1.6之前版本的历史记录是，从其他Git获取了一些提交之后，您现在希望将这些提交合并]到您的当前分支。有一段时间，在Git早期，整个[[remote概念不存在，因此没有远程跟踪名称：根本没有pull，因此也没有merge。因此，重要的是要立即合并他们的提交，以免Git运行垃圾回收过程并remove
在1.6以后的时代，即从2006年左右开始，收集提交并让它们坐在那里]一段时间是安全的，当您仔细查看，思考甚至忽略它们时，完全是一会儿。 remote名称 remote-trackingrebase引入了origin，可无限期保留这些提交。不再需要疯狂地将这些提交推入您自己的分支之一，以防止它们被删除。底线是：如果发现origin/master方便，请使用它。如果没有，那就不要。请记住，如果使用参数，则将使用的参数是它唯一的。只是origin的组合，加上立即的第二条命令将一些提取的提交合并到了[[current分支中。在大多数情况下，我发现这种[[in
origin/master，则将使用远程跟踪名称来命名传入的提交，例如git pull，但是如果确实使用git fetch，则不能
在以下位置使用这些名称git pull命令本身，因为它与不存在这些名称的远古时代兼容。1这种origin/master会在任何现代Git中更新git pull，但在1.8.4之前的Git版本中，git pull不会更新。2被选作合并或变基参数的提交是那些您在命令行上专门命名的引用中的提交（如果已命名）。否则，选择作为参数的（单个）提交是与当前分支的upstream设置相对应的提交。git fetch运行除合并或变基以外的其他命令作为第二个命令。在这些特殊情况下，最有趣的是进入一个完全空的存储库：在这里，origin/master和origin/master都不会做任何事情，因此git pull本质上只是运行git merge。这种特殊情况显然在任何给定的存储库中仅发生一次。