我一直无法得到这个问题的明确答案。
很长一段时间以来，在同事的建议下，我一直在这样做：
git fetch origin
git pull origin <mybranch>
我被告知(并且已经看到)如果你不先做git fetch，git pull的行为方式就不一样了。您不会获得任何远程更改。
但我在网上看到的只是git pull相当于git fetch后跟git merge。如果这是真的，git pull将包括git fetch，我不需要先明确git fetch，对吧？但事实似乎并非如此。
所以我正在寻找一些明确的文档来描述观察到的git pull行为。(我知道我可能还会得到很多建议来切换到git fetch→git merge;这也很好，但我对git pull真的很感兴趣。
我们可能应该将其作为重复项关闭，但在此之前，让我看看是否可以将其挤进去。
虽然git pull后面git fetch是git merge(或git rebase)，但确切的区别在于git pull如何运行git fetch。
具体说来：
$ git pull
或：
$ git pullremote-name branch-name
(或各种类似的变体)运行，不是普通的git fetch，不是git fetchremote-name，而是git fetchremote-name branch-name。
自 Git 版本 1.8.4 以来，这与该版本之前的差异较小：
git fetch origin master不像git fetch origin或git fetch没有更新refs/remotes/origin/master;这是一个早期 保持远程跟踪分支更新的设计决策 可预测，但在实践中，事实证明人们发现它更多 方便在我们有 机会，当我们运行git push时，我们一直在更新它们 无论如何，已经打破了原来的"可预测性"。
换句话说，如果git pull决定运行git fetch origin master，这将更新存储库中的origin/master- 但前提是您没有运行 Git 的古老版本，例如某些未命名的 Linux 发行版中包含的版本。
如果您运行git fetch origin，您将更新所有远程跟踪分支(前提是您有一个合理的配置，即使在上述古代版本的 Git 中，这也是默认设置)。 如果你运行git fetch origin master，你只会得到origin/master更新，而且只有当你的 Git 不是太荒谬地过时时。 由于git pull运行四个单词的变体，因此它只更新一个，甚至不更新远程跟踪分支。
我被告知(并且已经看到)如果你不首先执行 git fetch，git pull 的行为方式就不一样了。您不会获得任何远程更改。
通常，这不是真的，git pull 从远程拉取状态。
但我在网上看到的只是 git pull 相当于 git fetch 然后是 git merge。如果这是真的，
是的！
引用git-pull的手册页：
将来自远程存储库的更改合并到当前分支中。在默认模式下，git pull 是 git fetch 的简写，后跟 git merge FETCH_HEAD。
我认为这解决了它。
所以我正在寻找一些明确的文档
$ git help pull
git pull 是一个 get fetch，然后是一个 git 合并。 (或者您可以使用 --rebase 选项改基)。 所以不，你不需要在"git pull"之前做"git fetch">
键入"git 帮助获取"和"git 帮助拉取"进行描述
Git fetch 转到命名存储库，获取引用的对象(通常是提交)，获取它及其所有依赖对象，并将其存储在命名的远程跟踪分支中。 然后，您可以从那里合并或变基。"git merge origin/master"，或者你可以用"git checkout origin/master"查看它