Question

是否有人知道是否可以更改git flow以使用3个以上的分支？

目前我们使用标准工作流程：

dev -> feature/*  ->  dev
dev -> release/* -> master
master -> hotfix/* -> master & dev

然而，我们的设置现已大幅扩展，正在寻找以下工作流程

dev -> feature/* -> dev
dev -> stage/* -> staging
staging -> bug/* -> staging
staging -> release/* -> master & dev
master -> hotfix/* -> master & staging & dev

改进的工作流程将使开发人员能够继续构建和共享新功能，即使在测试分阶段发布期间也是如此。还允许其他开发人员修复即将发布的任何问题。

Answer 1

有可能吗？是的，您可以使用您想要的任何过程。 Git Flow是（1）一套关于如何在Git中使用分支的指南，以及（2）一组脚本来自动执行这些指南。在这个答案中，我将重点关注（1），但扩展脚本以帮助您实现所选解决方案应该很简单。

标准工作流程中缺少一件事：

dev    -> feature/*  ->  dev
dev    -> release/*  -> master (& dev)
master -> hotfix/*   -> master & dev

即，release分支需要合并回dev（如果他们有任何提交）。

您的新设置需要类似的修复：

dev     -> feature/* -> dev
dev     -> stage/*   -> staging (& dev)
staging -> bug/*     -> staging (& dev)
staging -> release/* -> master (& staging) & dev
master  -> hotfix/*  -> master & staging & dev

如您所见，必须完成的数字合并会以指数方式增加。

我有两个备选建议，一个是标准工作流程的轻微旋转，另一个是我目前用于项目的更简单的扩展工作流程。

标准Git流程

再次，作为参考，标准的Git Flow工作流程是：

dev    -> feature/*  ->  dev
dev    -> release/*  -> master (& dev)
master -> hotfix/*   -> master & dev

不要使用专用的长期staging分支部署到您的登台环境，而是将CI/CD系统设置为自动部署到暂存最新的release分支。< / p>

我推荐这个选项，因为它使事情变得最简单，但是可能很难设置CI系统来部署最新的release分支。

仅FF制作

以下是此设置的概述：

dev     -> feature/* -> dev
dev     -> release/* -> staging (& dev)
staging -> hotfix/*  -> staging & dev
staging -> --ff-only -> master

此设置对于需要非常稳定的生产部署非常有用。请注意， nothing 已合并到master;偶数hotfix es合并到staging。在暂存时测试release或hotfix时，请执行此操作以更新生产：

git checkout master
git merge --ff-only staging
git push origin master

此工作流程与您建议的工作流程非常接近，但仍然大大减少了合并的数量，并且还具有对标准git-flow脚本进行非常少的更改的好处。

git-flow更改默认工作流程

1 个答案:

标准Git流程

仅FF制作