尝试进行持续交付时具有功能切换的功能分支

Question

如果某些团队已经在使用功能分支并尝试实现持续交付，我试图了解为什么他们会使用功能切换。假设一个团队想要实现持续交付，并且可以借助功能切换或功能分支来实现。

通过功能切换，可以实现所谓的“发布切换”，让团队能够更快地发布。如果某个功能尚未准备好并且您只使用主分支，则可以切换它并发布代码。

特征分支的情况几乎相同。在这里，您可以拥有 3 个正在开发的功能，其中一个已经完成。然后，公司希望团队部署到生产环境。他们只选择该功能并将其合并并发布。

我看到一些团队在开发时同时使用这两种方法。 有这方面经验的人能告诉我一些有关它的事情吗？

希望你能理解。

Answer 1

我发现功能分支和功能切换共存的一些原因：

• 使用功能分支不需要付出任何努力（除了一些关于流程的讨论，任何方法都需要这些讨论），因此团队可能会从它们开始。最终，一个团队意识到功能切换是一个好主意并实施了它们，但到那时它们已经用于功能分支，因此他们继续使用这两种机制。
• 即使您已经制定了使用它们的方法和流程，使用功能切换比使用分支需要更多的努力。您需要围绕每个更改编写代码，这并不总是微不足道的。当它们达到目的时，您必须删除它们，这似乎微不足道，但显然难倒了一些开发人员。
• 分支有一个我能想到的真正潜在优势：在合并之前，它们完全不受团队其他成员的影响。如果您认为自己的作品还没有准备好向他人展示，您可能会想要这样做。