我对到处可见的这张图片感到困惑:
一个发布分支是基于开发创建的,然后合并到主AND开发中。我认为,它应该基于开发并直接合并到母版中。然后,应将整个master分支重新合并到development中,因此您可以确保master始终与development保持一致。在对master进行修复后,它们也将通过这种方法进入开发阶段。
现在,我想这是有原因的。有什么理由吗?这种做法会与历史混淆吗?
如果我正确理解您的问题,我相信答案是,如果您有发布分支,它可以防止代码冻结在开发团队中,然后开发团队可以继续进行工作并提出拉取请求并合并以进行开发。当以后发现发行分支需要修补程序时,我们可以在发行分支而不是开发分支中实现修补程序,因为我们不需要从开发中挑选麻烦就可以合并修补程序。这就是为什么master和development都发生合并过程的原因,因此两个分支将具有相同的修补程序。如果您将直接热修复程序插入主服务器,则您将失去对发行分支在特定时间点是系统的工作副本的信心。
在GitFlow中:
develop
分支中,您可以在稳定当前版本的同时开始为下一个版本创建新功能master
分支始终处于可释放状态,这意味着它包含您上次成功发布的版本所以您无法直接提交给master],master在发布分支中对所有内容进行测试后始终会收到提交。
您所指的是更接近现代CI / CD的方法:您正在处理的单个分支,每个人都试图保持其稳定并且]经常推送到该分支。但是然后,您实际上并不需要开发分支。您最终将基于基于主干的开发或小型功能分支,这些分支将被合并回到主分支。