与合并相比，将主题分支变基的缺点是什么？

Question

我目前的做法是在主开发分支上合并已经完成的话题分支。最近日志看起来有些混乱，我正在考虑改用rebase。

相比于使用merge来合并话题/特征分支，使用rebase可能存在哪些潜在的缺点？

- Eric

---

我曾经看到过在执行'git rebase'时出现“内存不足”的致命错误。 https://dev59.com/9mw15IYBdhLWcg3wLIzI - GoZoner

Answer 1

使用rebase的主要缺点是你必须只在本地使用它。也就是说，一旦某些内容被推送后，不要进行rebase。重写历史非常好，但一旦你开始在远程上玩弄历史记录，事情就会变得非常混乱。 编辑 另一个缺点是真实的历史事实上会丢失。这意味着，别的方面都好，但想要轻松返回到话题分支是不可能的，因为它看起来像是主干的一部分。这也使得撤销更改变得更加痛苦，因为你需要逐个挑选提交，尽力记住哪些提交来自原始的话题分支。如果你使用交互式rebase，或者更糟糕的是，压扁了你的提交，那么这可能会带来巨大的头痛。

- Chris Eberle

---

另一个缺点是将主题从主分支中还原变得困难吗？如果是，您能否在您的答案中加入这一点？ - Eric

@Eric 是的，那可能是一个潜在的缺点。我会更新我的答案。 - Chris Eberle

Answer 2

缺点包括修订版与开发过程中实际状态不匹配、失去使用像--first-parent等标志隐藏合并之间提交的能力，以及难以共享分支，如果您打算以后重新建基。如果您的日志看起来很疯狂，请再查看一下git help log。很可能有一组标志的组合可以使其看起来正是您想要的，而不会在需要灵活性时牺牲它。

- Karl Bielefeldt

Answer 3

一些原因：

• 最糟糕的问题：你必须协调好团队，确保每个人都使用rebase并理解为什么要使用它。根据我的经验，你必须具备高于普通开发人员的git理解能力，以免在使用rebase时遇到麻烦。你必须配置你的仓库，使得rebase成为默认的拉取策略。

• 通常来说，解决冲突更加困难。如果你在一个功能分支中有多个提交，那么你可能已经多次更改了同一段代码。如果发生冲突，你就需要多次修复。而如果使用合并，你只需要修复一次。

• 如果你总是提交可工作和经过测试的代码，你的提交历史记录不一定是可用的。这是一个罕见的事件，但这会对git bisect的使用造成影响。

顺便说一句，我喜欢使用rebase并推荐使用它来保持干净的历史记录，但你必须注意其中的注意事项。同时，请记住，更重要的是拥有良好的提交信息和提交粒度。

- neves