为什么对于git pull合并是默认行为？

Question

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

Answer 1

我假设您的问题是，为什么git pull默认行为是合并而不是为引入的更改重新设置基础。

答案很简单：Rebasing重新创建要重新建立基础的提交。然后，这些新的提交对象将替换旧的提交对象。但是那些新提交与旧提交完全不兼容。这会导致所有其他之前已撤回原始提交的用户都具有刚创建的重新创建的提交中不兼容的提交。因此，您有两个冲突的版本，且大多数都具有相同的更改。这通常意味着很多问题，因为您需要手动解决这些冲突（通过说出要保留的两个版本中的哪个；因此，如果重新设置基础，则其他所有版本都需要手动丢弃旧版本）。

这也是为什么您永远不要为已发布的提交重新设置基础的原因。

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

当然，在某些情况下重新部署就可以了。最值得注意的是，如果您在本地处理一些未发布的更改，并且想要更新存储库。然后，获取并重新定位您的本地更改就可以了，因为它们仅属于您自己，并且没人知道它们。但这始终应该是一个明确的操作，因此您不会犯任何错误。这就是为什么变基拉力只是一个选择的原因git pull -r。

Answer 2

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

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