Git rebase 和 merge 是不是没办法混着用？

我也是一直 rebase,团队有某几个人 commit 前都没有先 pull，所以他们每次都是 merge 。

所以一直都是混用，暂时没有遇到大的问题.就是那条线比较乱。

还有就是要求团队每个人按一定规范去提交代码比较困难。目前没有强制。

没理解，你们现在不就等于是混着用吗？

变基 vs. 合并
至此，你已在实战中学习了变基和合并的用法，你一定会想问，到底哪种方式更好。 在回答这个问题之前，让我们退后一步，想讨论一下提交历史到底意味着什么。

有一种观点认为，仓库的提交历史即是 记录实际发生过什么。 它是针对历史的文档，本身就有价值，不能乱改。 从这个角度看来，改变提交历史是一种亵渎，你使用 谎言 掩盖了实际发生过的事情。 如果由合并产生的提交历史是一团糟怎么办？ 既然事实就是如此，那么这些痕迹就应该被保留下来，让后人能够查阅。

另一种观点则正好相反，他们认为提交历史是 项目过程中发生的事。 没人会出版一本书的第一版草稿，软件维护手册也是需要反复修订才能方便使用。 持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事，怎么方便后来的读者就怎么写。

现在，让我们回到之前的问题上来，到底合并还是变基好？希望你能明白，这并没有一个简单的答案。Git 是一个非常强大的工具，它允许你对提交历史做许多事情，但每个团队、每个项目对此的需求并不相同。 既然你已经分别学习了两者的用法，相信你能够根据实际情况作出明智的选择。

总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史， 从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。

最好只用一种

我曾经做过尝试，结论是除非你自己是代码管理员，有权利可以拒绝别人的提交，否则你就只能自己玩 rebase，别人 merge 你自己 rebase 是没关系的。rebase 比 merge 稍微难理解，很多码农不肯去学习，很难强推。如果你通过重写历史的方式把别人的 merge 弄掉，整条分支线会变更，其他人都需要删掉分支重新 pull，就看你们团队人员多不多了。