Git“漏水”分支？

Question

我们通常在新的分支上进行功能开发，然后在主分支上修复错误。这一次，由于某些原因，其中一个功能分支有一个泄漏，它被合并回master，而它不应该合并。

从屏幕截图中，您可以看到我们有功能分支sms_open和121217。121217应该在我们的sprint之后合并到master中，然后sms_open分支有一个更长的时间估计，所以它需要在未来的版本中推迟。我搞不懂为什么sms_open提交609129d被合并了回来。我看到75e845b发生了不想要的合并，但这样做的开发人员否认sms_open正在被合并回来。有没有办法以某种方式来验证这一点？

仅供参考，这里使用的git工具是用于Mac的SourceTree。

​

​

Answer 1

当您从121217开始跟踪绿色的线时，您可以看到它已连接到sms_open。这意味着121217的历史是基于sms_open的(它是其父提交之一)。

因此，无论是谁创建了121217分支，都是基于sms_open而不是master (可能是错误的)。这可能是commit e70759c的作者。

当在Git中合并分支时，从分支到合并的所有提交都将是结果的一部分，这些提交还不是要合并到的分支的一部分。这就是为什么sms_open的提交也被合并了。

Answer 2

截图中有些可疑之处。“合并分支'xxx'”这样的消息是合并到主时的默认消息。

这里有commit c8cb6，它意味着蓝线是主线。但是还有75e8，这意味着黄线是主线。不幸的是，其他消息是匿名的，因此对理解发生了什么没有帮助。特别重要的是哪个提交来自哪个开发人员。-在我看来，似乎有人在master上工作，后来重命名了那个分支。(但我没有足够的细节可以告诉你。)

如果历史记录没有意义，可能会涉及到快进合并或强制推送，特别是ff合并，因为它根本没有记录在历史记录中。

如果你可以访问你的官方git存储库，那里的reflog可能会给你一个提示，谁在什么时候推了什么。