你会在pull中选择rebase和merge方法吗？

Question

我使用了SmartGit！ 我知道 rebase 和合并之间的区别，但我听说它被归类为疑难解答操作，并且不建议每日使用。所以SmartGit改为推荐这种方法。你会选择什么？

Answer 1

经验法则：

• 如果您已经发布了要重新定位或合并的提交，并且未指定数量的用户已经将它们放入其私有存储库克隆，那么merge是唯一的选择。

• 如果您还没有发布它们，或者您可以要求所有远程用户重新获取重新提交的提交，这对他们来说不会是一个很大的干扰，那么您可能会重新发布。< / p>

• 实际上，为了使未发布的提交的历史记录保持直接和干净，您应该重新定义它们。如果是如果您在以前的未发布的提交中发现错误，则应重置为已损坏的提交，修改它，然后通过新的固定提交重新绑定链的其余部分。

理由：

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

如果发布了一些提交，那些提交可以由其他存储库用户用于其衍生作品。重新提交已经发布的提交，要求所有其他用户反过来必须在新版本的提交上重新设计他们的工作。当然，它会让你的同事的生活更加艰难，如果没有可行的论据，我也不会推荐这种方法。

另一方面，在本地变更链中进行不必要的合并会使事情变得复杂，而且回购历史很快变得一团糟。这就是为什么rebase是一种重新组织/重新排序未发布的提交的推荐方法的原因。