为什么git pull merge是默认行为？

Question

通常当我们使用新的origin提交更新我们的本地存储库时，我们会执行git fetch，git rebase。但我们不做git fetch git merge。通常，原因是我们不想添加新的提交（合并提交），但只想在我们的代码之上获取所有新提交。那么为什么然后git pull的默认行为不是merge。我知道我们可以改变它，但是有更好的理由在fetch-rebase上使用fetch-merge。

Answer 1

我假设你的问题是为什么git pull默认行为是合并而不是改变拉入的更改。

答案很简单：Rebasing重新创建正在重新定位的提交。那些新的提交对象然后替换旧的提交对象。但是这些新提交与旧提交完全不兼容。这会导致之前撤消原始提交的所有其他用户与您刚刚重新创建的已重新提交的提交进行不兼容的提交。所以你有两个相互矛盾的版本，大多数都有相同的变化。这通常意味着很多问题，因为你需要手动修复这些冲突（通过说明要保留两个版本中的哪一个;所以如果你重新设置，其他的都需要手动抛弃旧版本。）

这也是永远不会重新发布已发布的提交的原因。

因此，默认解决方案是 merge ，因为合并是一种完全安全的操作，不会导致冲突。合并提交只是添加到历史记录中的提交，但不替换现有历史记录。是的，它可能会使历史变得更复杂，但它完全透明并且与之前存在的所有版本兼容。

当然，在某些情况下，变基就好了。最值得注意的是，如果您在本地处理某些未发布的更改，并且您想要更新您的存储库。然后获取和重新定位您的本地更改是好的，因为它们只属于您自己，而其他人都不知道它们。但这应该是一个明确的行动，所以你不要犯任何错误。这就是为什么推销拉力只是一个选择：git pull -r。

Answer 2

我认为它默认以这种方式工作，以避免重写本地历史记录，并改变现有提交的哈希值。这些提交可能已被推送到远程。 rebase是一个破坏性命令，默认情况下从遥控器中拉出更改不会破坏任何内容。

您可以使用git pull --rebase或只为此操作创建别名。