除了由此产生的git树结构，git pull与git fetch + git rebase之间是否有任何重要的区别？
问题描述：
我在开发团队工作，在git推送任何更改以避免合并冲突之前，首选使用方法git fetch，然后git rebase而不是git pull的方法。除了由此产生的git树结构，git pull与git fetch + git rebase之间是否有任何重要的区别？
除了视觉树结构的差异之外，还有一个具体原因吗？据http://mattsnider.com/git-rebase-versus-git-pull/fetch & rebase
“会产生一个更清洁的历史，没有多余的合并提交”
但两种方法之间是否有任何其他理由选择一个比其他？
答
git pull = git fetch + git merge
git pull --rebase或git pull -r = git fetch + git rebase
没有更多的，不低于;-)没有魔法。 所以你可以做第二个。
执行提取然后在两个不同的步骤中进行重定位的主要优点是第一个不会修改您的本地分支（绝对没有风险），因此您可以每次都执行该操作（甚至可以创建运行它的任务定期）。
而且一旦取出，你可以看看历史，把它比作你的提交，并决定你想要做什么和什么时候...
您可以配置'git的pull'来运行'git rebase'代替作为第二步'git merge'。最后，它对*操作*没有太大的区别，但我认为'git pull'通过隐藏实际涉及两个步骤的事实来为*人类*提供陡峭的解除服务：'git fetch'，然后第二步。 'pull'命令在语法上也是危险的，因为这种人为失败：运行'git pull origin b1 b2'并且最终做章鱼合并是很容易的，因为它看起来像'git pull'做了一些神奇的事情，但它确实没有。 – torek
'git merge'在不是快进合并时创建合并提交。合并提交不会像'commit-msg'那样调用一个钩子。在某些情况下，当你需要'commit-msg'来对每个新提交进行操作时，合并提交会被忽略，除非你修改它。 – ElpieKay