Git flow 的特性分支。

Question

团队目前的Git流程。

总共有3个分支。

main
develop
feature

在开发阶段时，如果有一个新的 Jira ticket，我们将从 develop 分支创建一个 feature 分支；完成 feature 后，我们将其合并到 develop 分支中；当我们想要更新主分支时，我们将 develop 合并到主分支中。

但是现在应用程序已经对公众开放，我们希望有更好的 Git 流程。与以往不同的是，如果我们完成了功能，我们会将其合并到 develop 分支中。然后测试人员会测试该功能是否没有缺陷。一旦测试人员测试完毕，他们将要求我们（开发人员）仅部署该功能，这与以前的做法完全不同。

例如，如果开发人员完成了 Feature A，并且测试人员已经在 develop 分支中验证了它，那么之后我们需要将只 Feature A 合并到主分支中。

因此，我想知道是否有任何建议的流程适用于这种情况。

- CCCC

---

交付范围通常是业务优先事项，而不是git的组织方式。每个发布都意味着一些准备工作，如果只有一个业务请求的功能，为什么要开发其他功能？如果业务请求其他功能，为什么QA只想要其中的一部分？ - The Dreams Wind

@The Dreams Wind 这意味着当功能 A 经过测试后，我必须将其推送到主分支，或者在完成功能 B 后将其推送到主分支等。 - CCCC

@The Dreams Wind 希望我们在完成单个功能后立即将新功能部署到主要版本。 - CCCC

您可能希望以一种自动化的方式来执行CI流程，使得每次合并都会为QA推出一个构建版本，这样他们就可以从可用的构建版本中选择每个功能所需的版本。如果QA团队要求某些特定功能的顺序，那么就意味着有三种选择：1）微观管理开发团队的进度，并在主要功能准备好之前人为地保留某些功能。2）将功能直接合并到主分支中，破坏与开发和质量门控的同步。3）实现功能切换，以编程方式隐藏已完成工作的某些部分。个人认为这些选项都不太实际。 - The Dreams Wind

@The Dreams Wind 但是如果我想使用旧的方式（将develop合并到主分支），我们如何确保在合并到主分支之前测试了develop分支上的所有功能呢？ 例如，如果我们在develop分支中完成了功能A、B、C，并且QA只验证了功能A和B，而我们希望将A和B合并到主分支中。 - CCCC

如果他们希望你尽快部署，那么你的开发分支已经过时了，你只需对功能分支进行QA测试，一旦QA测试完成，就将其合并到主分支。开发分支意味着产品开发周期较长，在此期间你会积累一些功能集，然后将它们全部合并/发布。你可以有一个发布分支（短期存在的分支，每个迭代周期一个（Scrum术语）），然后询问你的QA/业务需要下一个版本中包含什么内容，并只针对该发布分支开发。在迭代周期结束时，将该发布分支合并到主分支并开始新的发布。 - Dmitry

Answer 1

Git Flow最好的运作方式是定期发布一组功能，其状态存在于一个单独的提交中。这就是为什么Git Flow建议从（一个提交的）develop分支创建一个release分支，您希望测试该分支。这可能是一个或多个功能，但意图是在该提交中的所有功能都将被发布。对其中任何一个功能的错误修复都在release分支上完成，以便新的开发可以同时在develop上继续进行。

另一种思考Git Flow的方式是：

一旦将代码合并到develop中，它就打算在下一个发布中部署（如果当前正在进行，则在下一个发布之后）。

即使您希望进行的所需调整在概念上很微不足道，我认为这已经足够让您不再使用Git Flow了。如果您为每个功能创建了一个新的release分支，那么您可能仍然可以坚持使用Git Flow，但是您需要按创建顺序发布它们，否则您将需要做很多还原来跳过特定功能。

根据您的情况描述，我提出的解决方案是使用Git维护者使用的Git工作流程。更改包括：

1. 将您的develop分支重命名为next。
2. 定期将next重置为main。（每周一次或每个迭代经常很有效。）
3. 让开发人员从main分支开始新功能。
4. 将这些功能分支合并到next进行集成测试。
5. 一旦批准，将这些功能分支合并到main并部署到生产环境。

话虽如此，在我们公司的一个较大的代码库中，我们实际上采用了两种方法的结合。我们基本上以 Git Flow 为“标准”方式（特性分支仍然从develop分支中创建），但我们通过将特性分支合并到称为next的分支中来验证这些特性，有时会进行多次修复和合并，最后再将它们合并到develop分支中。当我们从develop分支创建一个release分支时，它已经相当稳定了，而在release分支上进行的错误修复通常很少。如果您希望有时发布多个特性，则此混合工作流可能适合您。但是，如果您通常的用例是一次发布一个特性，那么我可能会考虑跳过 Git Flow 的开销。

- TTT