反对git rebase的一个论点是，它是一个比合并更复杂的过程，如果多个开发人员共享一个功能分支，中游rebase意味着所有其他开发人员必须删除他们的本地分支并从中获取新的副本中央存储库（或者开始使用差异分支）。
在多个开发人员共享分支的场景中，git merge是一个更简单的工作流程。但是当功能完成时，最终合并为“主人”呢？如果不是一直使用'rebase'来与master保持同步，你会一直使用'merge'，但在最终交付'master'时你会使用交互式'rebase'来实现干净，线性的历史记录并且压制无趣的提交？特别是，当'merge'提交被重放或git如何处理时会发生什么？
答案 0 :(得分：1)
如果您最终强制推送，Rebase只是一个问题，但如果您这样做，任何操作都是一个问题。在您使用rebase进入目标分支的场景中，git处理完全正常并且只是重放合并，如果相同的合并会发生冲突，可能会发生冲突。对于大多数情况，如果相应的合并也存在问题，则rebase只会出现问题。
答案 1 :(得分：1)
通常，您希望避免通过推送来重新设置已公开的任何提交。在您的情况下，您可以放弃，因为您正在重新定义临时功能分支，并且因为您可以非常清楚地与您的团队（即在该分支上工作的那些）进行通信，一旦开发结束并且那些更改，分支基本上就会消失已被重新定位为你的主人。
除此之外，重新定位包含合并的分支并不存在问题。来自master的合并提交将从您的重新分支中消失（从那时起您已经重新定位，这些更改已经集成），您可以轻松地运行交互式合并之后以进一步清理历史记录