特性分支、beta分支和废弃特性

Question

我一直在思考关于在分布式版本控制系统中分支的最佳实践，比如git、mercurial (我每天都有经验和使用的两个dvcs)。

我一直这样做的方式在每一个方面都略有不同，但通常遵循以下指导方针：

• 主分支-与生产代码并发
• 开发分支-与"beta“代码并发
• 特性分支-用于特性开发

开发是在一个特性分支中完成的(通常是从主分支创建的，因此我们知道我们使用的是一个稳定的代码库)，当dev完成、评审和开发人员测试时，它会被推送/合并到开发/ beta分支中，在beta服务器上发布，然后进行测试。

如果一切顺利，该特性将得到批准，我们可以将其合并到主/稳定分支中，进行阶段测试，并将其投入生产。

不过，如果不顺利的话，事情就会破裂。例如，如果某个特性被取消或只是无限期地延迟，我们可能希望从dev/beta分支中删除它。但是，由于主/稳定(修补程序、内容更改等)和其他新特性合并到开发分支中，因此很难从该分支中删除单个特性。

我得出的结论是，这个工作流刚刚中断，但它似乎应该能工作。因此，具体而言：

• 是否有可能从这种类型的分支中删除特定的特性？
• 这只是一个破碎的工作流吗？

更广泛地说：

• 考虑到功能的长期开发，并且需要有一个分支与live并行，那么dvcs中涉及的最佳实践是什么？

Answer 1

我认为工作流的核心是很好的，基本上遵循这里提出的思想：一个成功的Git分支模型。但是，我认为它为您崩溃的原因是，在合并和测试过程中，您基本上是“一刀切”的：

• 特性分支应该基于开发分支，而不是稳定/主分支。长期的特性不断地基于开发分支的顶端。
• 只有在功能分支为下一个版本做好准备并获得批准时，才应该将它们合并到开发分支中(也就是说，在合并时，它肯定会进入下一个版本)。
• 在准备新版本时，发布分支将从开发分支中分离出来，在最终测试被合并到用于生产的稳定/主分支之前，将完成最终测试。

当一个特性依赖于另一个尚未合并到开发中的特性时，事情肯定会变得更加复杂，但是正如布朗博士在他的回答中提到的那样，我认为这里的“功能切换”是个好主意。几乎已完成的功能被合并到开发中，但已禁用以供生产使用。然后，依赖的特性将在开发的顶部重新构建，并在准备就绪时进行合并。

Answer 2

我认为在合并后删除一个已经集成的特性对于大多数VCS (或DVCS)来说是很困难的，所以您应该确保这种情况尽可能少发生。一些想法：

• 如果您有一个与批准有关的特性(例如，在确定您正在创建“正确”功能之前，首先需要进行可用性测试)，那么在将其集成到开发分支之前，一定要确保您的测试人员已经使用了来自特性分支的版本进行了有用的测试。因此，如果功能处于危险中，则可以避免集成。
• 据我的经验，与大型功能片相比，小功能片被废弃或延迟的风险更低，因为它可以使它们更容易、更快地准备生产。因此，尽量使功能片尽可能小。
• 如果您有一个更复杂的特性，由十几个(或更多)功能片组成，并且您希望最终用户只将该复杂特性视为“全部或无”，那么将特征切换引入您的代码中，并为每个片段使用一个特性分支，而不是整个过程。这实际上并不能使以后“解合并”任何特性代码变得更容易，但是，例如，在将一半的功能片集成到dev分支之后，如果有人决定不完成下一个版本的全部工作，您可以将完成的功能片留在dev分支中，而无需激活功能切换。因此，您的用户不会注意到在那里有一个半完成的功能。

编辑:如果你真的需要“拆解”某个特性，在某个时候，它的部分已经集成到开发分支中，并与其他变更集混在一起，那么您可以选择使用一个单独的特性分支(或者我应该说“类似特性的分支”)？为那项任务。您更改和/或删除该分支中代码的相关部分，开发人员-测试它，然后将该更改集再次集成到dev分支中。

EDIT2:有关功能切换的更多信息，请阅读马丁·福勒的博客文章。