在一个持续开发的Web项目(不是产品)中,我们目前具有以下分支策略,大致基于git flow:

develop分支:最新的工作版本
master分支:即将发布的版本/已发布的版本
功能分支:开发中的功能
hotfix分支:已发布版本中的紧急错误修复

母版是只读的,可通过来自dev或hotfix分支的拉取请求进行更新。每次更新都会构建候选发布版本并将其部署到登台系统。手动批准后,候选发布版将部署到生产中。
功能分支是根据开发或从上一次合并到master中的提交创建的。构建了来自功能分支的要开发的拉取请求,并将其部署到免费的测试系统中,在该系统中执行集成测试和验收测试(自动和手动)。经过成功测试和审查后,PR被合并,因此它将成为下一个发行版的一部分(即从开发到母版合并)。
我的目标
我想简化一下并摆脱掉开发分支。 developer分支主要是出于历史原因,并且由于它始终是经过成功测试的版本,因此我认为不必将其与master分开。删除它还将简化发布过程,因为不再有其他合并。
我有以下限制:

发布是计划好的,并且在功能分支时不应完全自动化
通常是短命的,有些不合并数周(例如重新设计),但也需要进行测试(当前是针对开放拉取请求的开发)
有时应在常规发行版之外发布单个功能,从而有效地将其修复。使用当前策略,我可以重新建立要素分支的基础,然后将其直接合并到master
中,这也发生了,我们需要在对外部系统进行分阶段失败后进行测试之后保留要素,
在不确定转换的地方:

目前,我正在构建请求测试以合并发布的提交。我可以统一一下吗?
当母版领先于最新版本时,如何处理修补程序。我应该直接从修补程序分支构建和部署发行版吗?
是否有一种明智的方法来处理在合并后应该从发行版中排除的功能?在这些情况下,单独的开发部门真的是一个优势吗?大多数情况下,我最终还是要手动还原和还原提交。


评论

似乎您一方面说您不需要DEV分支,但接着继续解释为什么您确实需要它。生存了数周的功能分支在分散了这么长时间后将很难合并。您确定要删除DEV吗?

@DaveSwersky好问题!我不确定,这就是为什么我要在这里问问题:)关于长期存在的功能分支:合并的困难是一个已经存在的问题,将被转移到另一个地方。通过从主分支返回常规合并,这是可行的。如果主分支是master会更困难吗?

长寿的分支机构始终是一个挑战,尽管合并到母版而不是DEV分支可能是更多的挑战。解决该问题的方法可能是更好地分解工作,以保持这些分支的生命周期短。如果您可以阻止主题/功能分支的寿命超过24-48小时,那么消除DEV可能会更好。

@FabianSchmengler您要删除dev分支的真正原因是什么?听起来确实像在事情未按计划进行的情况下需要它。

称它为master或develop或任何您想要的东西,如果您想拥有真正的CI,则将需要一个集成分支,或者如果将其委派给功能分支,则只能将它们与当前版本隔离进行外部集成。

#1 楼

恕我直言,您所面临的问题只是您采用的不良分支策略的副作用:您正在通过develop上的当前生产代码有效地耕作master上的新开发项目(即,向未来生产代码收敛的产品)。这就导致了矛盾的要求和问题,因为通常将来的代码与当前的代码有所不同:


新的开发使生产不稳定-将develop合并到master后看到的回归

稳定生产会减慢未来的发展-您需要稳定develop以使其足以整合到master中。问题,您只是将问题的develop特定部分转移到develop中。

更好的方法是将生产移至当前/将来的开发之后,以防止对未来的开发造成干扰发布,如“什么是您的分支模型?”中的图片所示:





请注意,我仅指的是释放上图中的分支,而不是树干上的分支。

为您准备的ork:


master分支消失了,如您所愿,被吸收到develop中速度限制(从未合并到生产中)。生产是从master标签/标签拉出的一个或多个master分支被认为与生产质量足够接近(可以在该分支中解决剩余待办事项的简短列表)如果需要的话)。这些分支只能从release接收直接的热修复和/或精心挑选的修复,它们永远不会与master或其他分支合并。
修补程序是直接提交到master的分支

如果此修补程序仅适用于生产版本而不适用于master,则它将直接提交给release分支。如果同时适用于两者,则通常首先将其提交给master,也将其同时提交给release分支。

现在查看进入master的内容(已超出当前值release分支已关闭),您有2个选择:


像今天一样继续使用功能分支,只是它们基于master而不是release。仍然可以将它们转换为热修复程序-您只需将它们重新设置为相应的master分支,而不是develop

切换到持续集成并获得其收益(可以随时进行) ,包括以渐进的方式-逐渐拉动越来越少的功能分支。

如果您喜欢这种方法,那么这就是您今天所处的位置:


建立发布命名策略:


您不能有一个同名的正在进行的发布分支
您不能(实际上不应)变基或同步生产发布分支


立即从release中拉出一个master分支,遵循该命名策略
不再提交到releaseX中,它们很快就会直接进入master。 />将develop合并到master

指示开发人员将工作空间基于develop而不是master
打开master进行提交
根据需要删除develop(或将其永久锁定/只读以供参考)


评论


感谢您的详细建议。我不确定发布分支是否是产品开发之外的一个好主意,但我会重新考虑,这对于该项目可能有意义

–法比安·施蒙格勒(Fabian Schmengler)
17年3月31日在19:39

您还拥有持续部署的替代方案,该方案将开发与生产置于同一位置(而不是进行或进行之前),但为此您需要进行文化转变(因为这意味着放弃所有集成和功能分支)。

–丹·科尼莱斯库(Dan Cornilescu)
17年3月31日在20:04

我知道那个图:)

–paul_h
17年4月1日在23:10

我对先在master中提交修补程序,然后选择发布进行修复有疑问。示例-我的经理要求提供修补程序。如果我在master上实现它,然后将其放入发布分支,则它可能会(根据墨菲定律,master的代码更改会影响此修补程序)与发布分支的状态不兼容。所以,现在我必须花时间重写专门针对发行分支的修补程序,并向经理解释为什么我不能尽快在发行分支上解决此问题,以便尽快提供它,然后再处理以适应该修补程序。主。

– JustAMartin
20年5月6日在13:01

@JustAMartin:这两个命令同样有效,master和release分支是完全独立的。但是,如果您有不兼容的问题,则此修补程序不是同等适用的,因此请不要挑剔。

–丹·科尼莱斯库(Dan Cornilescu)
20年5月6日15:51



#2 楼

假设您取出了master分支(如果您以后喜欢,可以将development重命名为master,以使您的团队感到困惑),然后只需将标签用于developer或hotfix分支上的发布即可。您取出了一个分支,但区别只是语法上的更改。为了改变而进行更改。

现在让我们说您实际上是通过保持锁定的master分支来进行开发的。将会发生的是,代码集成会变慢,它在功能分支中的寿命更长,尤其是在发布日期之前。这将增加每次合并的难度并减慢该过程的速度。

在您设定的约束范围内,我看不到进行此类更改的任何积极影响。这将需要放宽约束,尤其是第一个约束。

#3 楼

您已经在每个pull-request和hot-fix分支上构建和测试代码。这意味着总的来说,所有在请求请求上待处理的分支的总和就是您的虚拟develop分支。

您可以在测试环境中将几个请求合并到一个分支中时创建一个系统。没有发布到主存储库的临时分支。该分支用于集成包括master和几个其他请求请求的测试环境,但是一旦完成测试,该分支将不再在任何地方可用。

master创建发行版时,您通常会在该版本上创建标签。以后的修补程序可以使用该标记创建一个新的修补程序分支,从该分支可以进行部署,即使master的边缘已经在前面。在此修补程序分支上,您可能还会标记一个次要发行版,并确保所做的更改已合并到master中。

从git中很难删除发行版中的合并功能。最好的机制是在合并提交上使用git revert。但这几乎使这些功能/更改无法恢复,历史变得一团糟。

特征标记是处理代码部署和功能发布分离的更好方法。如果您的开发人员可以在代码本身的某些条件下隐藏其功能,则可以部署他们的代码,但请关闭该功能。这是一个单独的主题,但是存在许多与此有关的信息(包括对devops.SE的问答)。

#4 楼

@ dan-cornilescu很好地解决了您的特定问题,但此处提供了基于中继的开发的更一般情况(在持续交付,精益企业和DevOps手册中提到):https://trunkbaseddevelopment.com/