我敢打赌，当你把东西合并到master中时，你并没有创建真正的合并。让我解释一下。假设你有这些分支：

*   third commit in master (master)
| * third commit in develop (develop)
| * another commit in develop
| * a commit in develop
* | another commit in master
* | a commit in master
|/
* initial commit

假设我们将develop合并（真正的合并）为master：

* Merge develop into master (master)
|\
* | third commit in master
| * third commit in develop (develop)
| * another commit in develop
| * a commit in develop
* | another commit in master
* | a commit in master
|/
* initial commit

现在假设在develop中完成了更多的工作：

*   Something else in master (master)
| * 5th commit in develop (develop)
| * 4th commit in develop
* | Merge develop into master
|\|
* | third commit in master
| * third commit in develop
| * another commit in develop
| * a commit in develop
* | another commit in master
* | a commit in master
|/
* initial commit

如果你让git把develop合并到master中，git需要（粗略地）寻找它们的最新共同祖先....两个分支中出现的最新提交是什么？third commit in develop，对吗？因此，git在合并时需要考虑的就是这棵树：

*   Something else in master (master)
| * 5th commit in develop (develop)
| * 4th commit in develop
* | Merge develop into master
 \|
  * third commit in develop

但是如果你在合并的时候做了 * squashes * 会发生什么呢？让我们看看如果你做了squashes，* first * merge的结果：

* Merge develop into master (master)
*   third commit in master
| * third commit in develop (develop)
| * another commit in develop
| * a commit in develop
* | another commit in master
* | a commit in master
|/
* initial commit

第一次合并和真正的合并之间的树 * 几乎 * 是相同的...... * 但是 * 您可以看到，与第一次合并不同的是，没有关系（假设）合并提交和源分支（develop）...而这是一个交易破坏者，因为，即使develop分支 * 不 * 移动，如果你试图再次合并，你能看到最新的共同祖先是什么吗？2这就是为什么你仍然看到一些提交被合并到新的PR中。
底线：当合并到master的东西，* 不要挤压 *，除非你知道你在做什么。
经验法则是，如果你正在合并长时间运行的分支，你 * 不要 * 压缩。一个在你合并的那一刻即将死亡的特征分支可以被压缩合并。