带有UAT层的Git流

Question

我读了很多关于流行的git工作流的文章，包括一个成功的Git分支模型、合并、重基和摘樱桃，但是我仍然无法将所有这些应用到如何解决下面描述的问题上。我觉得摘樱桃也许会有帮助，但我不确定这是不是最好的主意。

假设我有三个开发人员负责处理分支f1、f2和f3中的三个特性，这些特性被合并到一个开发分支中，创建3在另一个之上提交。这些更改通过customer进行，客户认为f1和f3可以正常运行，但是f2需要做一些工作。

我怎样才能做到这一点？有哪些好的实践方法可以让f1和f3在当前版本中运行，而f2可以在下一个版本中运行？

谢谢。

Answer 1

您的问题超出了正常的git工作流，可以通过多种方式处理。

如果在UAT过程中发现的问题非常小，并且可以“在客户等待时”进行修复，那么您可以快速修复，然后是一个新的f2 UAT和三个特性的发布。

如果问题更严重，您可以将f2合并到开发中，进行回归测试以检查是否有任何故障，然后释放其余的特性。

如果在UAT期间来自客户的评论被认为是相当常见的，那么在这个特性被实际合并到开发之前，考虑与客户做一个(预)UAT是一个好主意。然后，您可以在它影响其他特性的发布计划之前，将其从特性中剔除出来。

如果预期多个正在开发的特性会相互影响，您还可以创建临时分支，在这些分支中集成这些特性，以便对这两个特性进行测试。

Answer 2

我认为这个问题没有技术上的解决办法。我过去也有过类似的情况，从技术上(通过拥有独立的分支)来解决这个问题，充其量只能是累赘，最坏的情况也是如此。

如果在开发过程的后期，您需要考虑将它们集成到最终产品中的其他方法，而这些特性实际上已成为您的最终版本。实际上，您应该考虑教育客户，仅仅为了推迟实际的推出而做所有这些前期开发工作本身就是个坏主意--但我知道这有多么困难。

一个例子(不是在每种情况下都是解决方案)是定期将代码合并到开发分支中(使用来自“成功的Git分支模型”的模型)，但是在运行时有一个功能切换以决定该特性是否实际是活动的和可见的。