通常当我们用新的原始提交更新本地存储库时，我们会执行 git fetch、git rebase。但是我们不做git fetch git merge。通常，原因是我们不想添加新提交( merge 提交)，而只是想在我们的代码之上获取所有新提交。那么为什么 git pull 的默认行为不是 merge 。我知道我们可以更改它，但是是否有更好的理由使用 fetch-merge 而不是 fetch-rebase。
最佳答案
我假设您的问题是为什么使用 git pull 默认行为是 merge 而不是 rebase 引入的更改。
答案相当简单: rebase 会重新创建正在 rebase 的提交。这些新的提交对象然后替换旧的。但是那些新的提交与旧的完全不兼容。这会导致之前 pull 原始提交的所有其他用户的提交与您刚刚重新创建的重新设置的提交不兼容。因此，您有两个相互冲突的版本，其中大部分更改相同。这通常意味着很多问题，因为您需要手动解决这些冲突(通过说明要保留两个版本中的哪一个；因此，如果您重新设置基准，其他版本都需要丢弃旧版本——手动)。
这也是为什么您应该永远不要对已发布的提交进行 rebase 。
所以默认的解决方案是 merge ，因为 merge 是一个完全安全的操作，不会引起冲突。 merge 提交只是添加到历史记录的提交，但不会替换现有的历史记录。是的，这可能会使历史变得更加复杂，但它是完全透明的，并且与之前存在的所有版本兼容。
当然，在某些情况下， rebase 就可以了。最值得注意的是，如果您在本地处理一些未发布的更改并且想要更新您的存储库。然后获取和 rebase 您的本地更改 就可以了，因为它们只属于您自己，还没有其他人知道它们。但这应该始终是一个明确的 Action ，所以你不会犯任何错误。这就是为什么 rebase pull 只是一个选项:git pull -r。
关于git - 为什么 git pull merge 是默认行为？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33258056/