我正在试图弄清楚我是否能够使用改进的gitflow Git工作流程，而且我正在努力（不确定它是否相关，但计划使用Atlassian Stash）：
我们目前使用CVS，并且有多个正在进行的大型项目。我们每个月都会进行新的项目生产发布，但每个项目可能在1周到6个月之间进行开发。我们还做每周维护版本。积极开发中最多可以有十几个项目。我们还需要能够对每个项目分支进行夜间回归测试以及维护。考虑到CVS的每个文件的性质，我们在需要大规模合并时将六个开发人员之间的手动合并分开。
到目前为止，我最好的想法是使用修改后的gitflow，我们将拥有以下分支：
master：目前正在制作什么
开发：下一个生产版本的开发分支，将在下一个版本发布的项目分支将在这里合并，以及不向大型项目发布的小功能（新功能和生产错误修复）
project / project_name：项目开发/集成/测试分支。这是分支开发，并在项目开发完成时合并回来开发。如果某些project / project_name分支需要正在开发的项目的功能，则它们可以从现有的project / project_name分支中分支出来。
feature / ticket_no：功能分支，从开发分支出来，用于较小的非项目功能。对于大型项目，从project / project_name分支。
release / release_number：发布分支，从开发分支分支出来，因为我们决定缩短发布时间。合并为主人。
bugfix / ticket_no：bugfix分支，从发布/ release_number分支分支出来，用于QA发现的错误。合并回发行版/ release_number并开发。
hostix / ticket_no：紧急生产问题的修补程序。从主人分支出来。合并为主人，发展和发布分支机构。
这听起来是否可行，或者我是否会因为巨大的合并复杂性而在这里拍摄自己？有关替代方法的任何建议吗？
更频繁地释放不可能为获得批准的停机时间做有限的能力。