我目前的做法是在主开发分支上合并已经完成的话题分支。最近日志看起来有些混乱,我正在考虑改用rebase
。
相比于使用merge
来合并话题/特征分支,使用rebase
可能存在哪些潜在的缺点?
我目前的做法是在主开发分支上合并已经完成的话题分支。最近日志看起来有些混乱,我正在考虑改用rebase
。
相比于使用merge
来合并话题/特征分支,使用rebase
可能存在哪些潜在的缺点?
缺点包括修订版与开发过程中实际状态不匹配、失去使用像--first-parent
等标志隐藏合并之间提交的能力,以及难以共享分支,如果您打算以后重新建基。如果您的日志看起来很疯狂,请再查看一下git help log
。很可能有一组标志的组合可以使其看起来正是您想要的,而不会在需要灵活性时牺牲它。
一些原因:
最糟糕的问题:你必须协调好团队,确保每个人都使用rebase并理解为什么要使用它。根据我的经验,你必须具备高于普通开发人员的git理解能力,以免在使用rebase时遇到麻烦。你必须配置你的仓库,使得rebase成为默认的拉取策略。
通常来说,解决冲突更加困难。如果你在一个功能分支中有多个提交,那么你可能已经多次更改了同一段代码。如果发生冲突,你就需要多次修复。而如果使用合并,你只需要修复一次。
如果你总是提交可工作和经过测试的代码,你的提交历史记录不一定是可用的。这是一个罕见的事件,但这会对git bisect的使用造成影响。
顺便说一句,我喜欢使用rebase并推荐使用它来保持干净的历史记录,但你必须注意其中的注意事项。同时,请记住,更重要的是拥有良好的提交信息和提交粒度。