TL;DR这是默认BitBucket合并策略的问题。
转到settings-〉merge strategy，将默认合并策略从“merge commit”更改为“rebase and fast-forward”。

合并提交：默认策略是“合并提交”，这是一个错误的默认策略。PR会添加带有原始提交创建日期的提交。

例如，如果你在两周前做了一个修复，今天最终合并。你的提交日期是两周前。当PR合并时，BitBucket会重写历史记录，添加日期为两周前的提交（尽管它发生在今天），BitBucket会添加一个日期为今天的占位符合并提交（表示合并发生在今天）。
最终的结果是，这个提交是在过去几周发生的其他提交之间发生的。要理解任何代码真正交付的时间是非常混乱的。

重定基数并合并：这是“merge commit”的等价物，也是一个更好的默认值。rebase意味着提交日期被刷新到合并的时间。有一个额外的占位符merge commit指示合并已经完成。
变基和快进：提交日期被刷新为合并的时间。没有额外的占位符合并提交。合并提交是不必要的，它是上一个提交消息的副本。这是最简单的模式，通常是开发人员在合并时所期望的。

注意：这与没有额外合并提交的“rebase and merge”相同。这两种策略都是合理的默认策略，并且是等效的，这取决于您对是否有额外合并提交的看法。

squash：squash策略会将PR中的所有提交都压缩到一个提交中。它隐式地在合并时进行了一次重新定基和一次新的提交。提交消息被合并在一起，结果可能会出乎意料。我个人觉得使用PR上的“Squash”按钮并输入一个有意义的提交消息会更好。

挤压警告：默认情况下，压缩模式会以意想不到的方式合并和删除提交消息。在测试存储库中尝试一下，看看你会得到什么。有一个非常重要的设置“最大摘要”，你可能想将其设置为“0”。

如何着手在整个组织范围内确定合并策略：您可能会发现您的团队或组织经常遇到问题，无法识别bug是何时发布的，因为git历史记录无法理解。您可以通过调整合并策略来减轻这种痛苦，但人们可能不喜欢更改，不愿意编辑BitBucket设置（git是一个永无止境的蠕虫罐头！）你可以循序渐进。首先，你将合并策略从“merge commit”修改为“rebase and merge”，这是同样的事情，但理智。开发人员会习惯它，并意识到它更好。几个月后，他们会注意到并询问重复的合并提交，这是当你纠正合并策略“rebase和快进”。