问题描述
在开发过程中遇到了一个问题。他们有4个环境（prod/preprod/SIT/DEV），两个主分支（Master和Develop），两个开发人员（One和Two）在开发功能。开发人员One创建了一个功能（Feature A），然后将该功能合并到Develop分支中。开发人员Two也创建了一个功能（Feature B），并进行了相同的操作，将创建的功能合并到Develop分支中。现在，Develop分支上有两个功能（A和B）。当业务所有者决定只选择一个功能（feature A）时，应该采取什么样的正确方法？在实施DevOps解决方案时，应该遵循什么样的GIT工作流程？请注意，我只提到了两个开发人员和两个功能，实际上可能同时有更多的开发人员和功能，因此我需要知道最佳的方法。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
由于您的产品是单个发布版本的产品，有一种考虑的方法是保留Develop分支或不保留它：
– 保留Develop分支的好处是，即使Develop分支不稳定无法合并到Master分支，您仍然可以随时在Master中引入热修复。但这意味着您需要保持两个关注点，而不是一个 – 两个分支都需要保持稳定。为了防止两个分支分叉，需要不断进行来回合并，这将增加额外的工作量。在两个分支之间切换可能会导致上下文切换的开销相当大。
– 另一种方法是摒弃Develop分支（参考如何摒弃Develop分支以简化Git工作流程），直接在Master中进行集成，这样可以减少携带两个分支的开销。发布将简单地成为Master分支的标记版本。但是，为当前发布版本获取热修复需要分支足够稳定（实际上准备好进行新发布的状态）的任何时刻。这也是期望的，并且是可以实现的（需要一些努力）。
在继续在独立的分支上开发功能（在单独的、可能存在很长时间的功能分支上）并经历集成困境的实践背景下，可以改进的一点是业务所有者和开发团队之间的更好沟通：在将功能B集成到产品中之后决定放弃功能B实际上等同于在游戏后期添加一个新功能C。
另一种（我认为更好的）选择是切换到持续集成实践：功能将直接在Master中开发（使用非常短暂的分支，携带更容易处理的微小增量更改，理想情况下在不到1天的时间内合并回Master），在功能切换/功能标志的支持下：
– 在开发过程中，默认情况下禁用功能，使Master在实质上等同于当前发布版本，准备接收热修复（如果需要的话）。
– 可以同时为任意数量的功能（或功能组合）在各个环境中单独启用标志，以确定相应功能的进展/准备情况。这可以作为自动化CI系统的不同验证步骤同时进行，无论其大小、开发阶段或持续时间如何。
– 一旦功能准备就绪并且业务所有者决定接受它，就在一个微小的提交中打开相应的标志，并通过新的标签将功能引入到下一个发布中。没有大规模的分支合并，没有意外的风险，一切都应该像往常一样 – 所有问题应该已经解决。这是一个更可预测（也更少压力）的开发过程。
– 在一段时间内保留标志支持代码还允许在后续发布中逐步删除功能，通过在CI系统验证阶段禁用标志来进行。但最终应该作为后台代码库维护任务进行清理功能标志和支持代码，使功能永久化。
在许多功能同时开发的大型项目中，我认为这种方法是唯一合理的选择。