我们通常在新分支上进行功能开发，然后在主分支上进行错误修复。这一次，由于某种原因，其中一个功能分支出现了泄漏，它在不应该出现的情况下被合并回 master。
从截图中，你可以看到我们有特性分支 sms_open 和 121217。121217 应该在我们的 sprint 之后合并到 master 中，然后 sms_open 分支有更长的时间估计，因此需要在未来的版本中推回。我无法弄清楚为什么 sms_open 提交 609129d 被合并回。我看到在 75e845b 发生了不需要的合并，但这样做的开发人员否认 sms_open 被合并回来。有没有办法以任何方式验证这一点？
仅供参考，这里使用的 git 工具是 Mac OS 的 SourceTree。
当您从 开始向下追踪绿色线时121217，您可以看到它连接到sms_open。这意味着历史121217基于sms_open（它是其父提交之一）。
因此，无论是谁启动了121217分支，都基于它sms_open而不是master（可能是错误的）。这可能是 commit 的作者e70759c。
当在 Git 中合并一个分支时，所有从分支到合并的提交，但还不是被合并到的分支的一部分，都将成为结果的一部分。这就是为什么 的提交sms_open也被合并的原因。
该屏幕截图中有一些可疑之处。像“Merge branch 'xxx'”这样的消息是合并到master时的默认消息。
有提交 c8cb6 这意味着蓝线是主线。但随后有 75e8 表示黄线是主线。不幸的是，其他消息是匿名的，因此对了解正在发生的事情没有帮助。哪个提交来自哪个开发人员尤其重要。- 在我看来，好像有人在 master 上工作，后来重命名了那个分支。（但我没有足够的细节可以告诉。）
如果历史记录没有意义，则可能涉及快进合并或强制推送，尤其是 ff-merge 是卑鄙的，因为它根本没有记录在历史记录中。
如果您可以访问您的官方 git 存储库，那里的 reflogs 可能会提示您谁推送了什么以及何时推送。