Git特性分支策略允许未经批准的“标记”特性。

Question

上下文

我们目前的操作由三台服务器组成: QA是devs尝试新功能的游乐场；Platform是面向客户的实时应用程序；Mock是平台的副本，是在发布到平台之前需要测试的新版本的分阶段区域。

我们的分支策略遵循这三台服务器。QA服务器有QA分支，Mock分支用于Mock，Master用于平台。当请求一个新特性时，特性分支将从Master分支到devs本地机器上开发。功能完成后，特性分支将合并到QA分支中进行测试/批准。当发布时间到来时，我们会选择所有已批准的特性分支，并将它们合并到Mock分支中进行最终版本测试。在发布测试之后，Mock分支被标记为下一个版本，并合并到平台中。

症状

我们一直在使用此策略处理的主要问题是，完成某个功能的devs将在转移到下一个特性时意外地从新完成的(或有时仍在进行中)特性分支中分支，而不是主分支。这意味着，当已批准的特性被添加到Mock中进行最终版本评审时，它们通常可以携带未经批准的特性，因为它们位于相同的特性分支中。

问题

是否有一种自动化的方法可以遍历每个特性分支，以检查自上一次发布标记以来其历史上是否没有其他特性分支？我可以手动完成(偶尔也会这样做)，但这会变得很麻烦。我还可以编写自己的脚本，查看自上一个git标记以来是否有任何分支共享相同的提交，如果不存在这种自动化。

我没有在DevOps训练-如果你看到一个明显的问题与这个开发周期，请指出给我！

Answer 1

从技术上讲，我猜像这样的东西会打印出在任何特定分支和您的主分支之间的任何分支：

for hash in $(git log --format=%h master..); do if git branch --contains=$hash | grep -qv $(git name-rev HEAD | sed -e 's#HEAD ##g'); then git branch --contains=$hash | grep -v $(git name-rev HEAD | sed -e 's#HEAD ##g'); fi; done

但从根本上讲，这里可能存在一个潜在的问题，我不太了解您的工作流程或与您一起工作的团队，但在我看来，开发人员不太可能意外地创建一个基于另一个特性分支的新特性分支，除非他们实际上希望在另一个特性分支中添加一些代码，也许是在交付新特性时重用。

看起来，您可能会非常快速和轻松地对您的流程进行许多改进，只需确保当前正在完成的所有功能都包含在下一个版本中，因此，一旦获得批准，cN就会被合并到一个预发布分支中。从那里开始，任何从预发布分支获取的分支都应该只包含打算发布的特性，但这意味着如果开发人员编写的代码适用于多个问题，那么一旦合并，他们几乎可以立即重用它。

虽然我不能完全确定我是否理解您所面临的问题，但在我看来，代码在两个分支中的存在实际上并不是一个问题，它只是代码重用。如果其中一个分支是从发行版中提取出来的，那么可以，正在重用的代码仍然需要保留吗？