推荐的git工作流允许独立部署功能

在我们的组织中,我们目前使用以下流程。

特性分支从生产分支分叉。特性在开发人员机器上的特性分支中实现。然后将特征分支合并到 develop 自动部署在登台服务器上的分支。

此功能由登台服务器上的用户测试,如果业务部门认为它是好的,并且是时候将其部署到实时服务器上,则将第二次合并功能分支,这次合并到 production 然后部署在生产服务器上的分支。

但由于种种原因,有些功能被放弃了。例如,业务部门认为现在还没有时间将该功能部署到live服务器。或者也许不再需要了。或者我们一年后再谈。在我的照片上 feature/1 从未融入 生产 分支但合并为 发展 分支。

这意味着 发展 分支越来越偏离 生产 分支。请注意 发展 是 从未 合并到 生产 (在规范git流中, 发展 合并到 生产 通过使用 release 分支机构)。

在我看来,这个工作流程需要大量的体力劳动。因为 生产 和 发展 是不同的,当要素分支合并到 发展 为了测试。这也很容易出错,因为我们在 发展 那永远不会消失。它不仅使合并变得复杂,而且还意味着特性分支代码在 发展 和 生产 分支,因为旧的未合并代码会影响功能代码。

而且,我有一种感觉,随着每一个新特性的出现,这将使工作变得越来越复杂,因为 发展 和 生产 将不可避免地增长。在流动中没有一点 发展 和 生产 是一致的,所以我担心一年后,也许10000+提交之后,合并将变得太复杂,无法处理。即使现在我们有合并错误。有些很明显,有些很微妙,很难找到。

我已经多次向CTO提出这个问题,即这个流程本身效率低下,而且容易出错。但他坚持认为,这个流程是最优的,因为它允许业务选择何时将功能部署到生产中。此外,他还声称,他在大公司以前的工作中使用了完全相同的流程。

我也有很多经验,但我从未见过这样的流量,我也从未在书或博客文章中读到过这样的流量。

我有两个问题:

1. 是这样的流动(在 发展 和 生产 是否经常出现分歧)是否确实用于大型团队?
2. 如果我认为它充其量是次优的,那么说服CTO迁移到更好的流(例如,规范的git流)的最佳方法是什么?