Git 在pull中，您会在rebase和merge方法之间选择什么？

我使用了SmartGit！ 我知道重新设置基础和合并之间的区别，但我听说重新设置基础将其归类为故障排除操作，不建议日常使用。因此，SmartGit将重新命名该方法。你会选择什么

经验法则：

• 如果您已经发布了要重定基础或合并的提交，并且有未指定数量的用户已将其放入其私有存储库克隆中，则合并是唯一的选项

• 如果您还没有发布它们，或者您可以要求所有远程用户重新获取已重定基址的提交，而这对他们来说不会造成太大的干扰，那么您可以重定基址

• 实际上，为了保持未发布提交的历史记录的清晰，您应该重新设置它们的基础。例如，如果您在以前未发布的提交中发现错误，则应重置为已断开的提交，对其进行修改，然后将链的其余部分重新设置为新的固定提交

理由：

在git和[某些]其他DVCS中，提交的父级是提交不可分割的属性。因此，如果父属性发生更改，则会生成一个全新的提交，即使它与原始提交具有相同的源树。这同样适用于“修改后的提交”（修改期间至少更改提交时间）

如果发布了一些提交，那么其他存储库用户可以将这些提交用于其衍生作品。对已经发布的提交进行重定基址，要求所有其他用户反过来必须在新版本的提交上对其作品进行重定基址。当然，这会让同事的生活更加艰难，如果没有可行的理由，我不会推荐这种方法

---

另一方面，在本地变更链中进行不必要的合并会使事情变得复杂，回购历史很快就会变得一团糟。这就是为什么

rebase

是一种推荐的重新组织/重新排序未发布的提交集的方法。

谁说不推荐在日常使用中使用rebase？我每天使用rebase。我认为这主要是基于意见。非常感谢你的可能的重复！我和我的同事一起工作，有时第三个用户会拉生产部门