Git工作流/gitflow-多个并发大型项目

我正试图弄清楚我是否能够利用一个修改过的gitflow Git工作流，我不确定它是否相关，但计划使用Atlassian Stash：

我们目前使用CVS，并且有多个正在进行的大型项目。我们每个月都会发布新的项目制作版本，但每个项目的开发周期可能在1周到6个月之间。我们也做每周的维护发布。可能有大约十几个项目在积极开发中。我们还需要能够在每个项目分支上运行夜间回归测试以及维护。考虑到CVS的每个文件性质，当需要大规模合并时，我们会在六个开发人员之间拆分手动合并

到目前为止，我的最佳想法是使用修改后的gitflow，其中我们将有以下分支：

大师：目前正在生产什么

开发：下一个生产版本的开发分支，将与下一个版本一起发布的项目分支将在这里合并，以及没有发布到更大项目的小功能，包括新功能和生产错误修复

项目/项目名称：项目开发/集成/测试分支机构。这是从develope分支出来的，在项目开发完成后合并回develope。如果某些项目/项目名称分支需要开发中项目的功能，则可以将其从现有项目/项目名称分支中分支出来

功能/票证号：功能分支，从开发分支出来，用于较小的非项目功能。从较大项目的项目/项目名称分支

release/release_number：发布分支，从开发分支分支分支出来，因为我们决定是时候削减发布了。合并为master

错误修复/票证号：错误修复分支，从QA发现的错误的发布/发布号分支分支分支。合并回发布/发布号并开发

hostix/ticket_no:针对紧急生产问题的修补程序。从主人那里分支出来。合并到主、开发和发布分支中

这听起来可行吗，或者我在这里开枪打中了自己的脚，因为将出现巨大的合并复杂性？对替代方法有什么建议吗

---

更频繁地发布并不能限制获得发布批准的停机时间。

您描述的工作流程听起来与我在过去两个工作场所看到的非常相似。Git最大的优点是创建一个新分支花费不多。因此，尽管在CVS中创建如此多的分支可能会受到沉重的惩罚，但在Git中，您将发现可以在几分钟内创建整个工作流

您提到了Atlassian Stash，值得一提的是，这是指您计划使用的存储库。存储库通常是远程位置，您的团队将在其中存储来自所有分支的提交。Git就是Git，无论您使用的是GitHub、Stash、BitBucket还是任何其他存储库，因此您拥有的功能都不会因repo而改变。然而，回购协议通常会添加一些工具，以使远程分支的管理更加容易。作为企业级回购，Stash在这方面非常突出，它应该能够处理您的用例

也就是说，在使用Git时，合并冲突不一定会减少。在Git中，让多个开发人员解决单个合并冲突并不常见

另一方面，Git不能很好地处理开箱即用的二进制文件。因此，如果您当前的CVS repo中包含了二进制文件，那么您将希望在采用Git之前检查所有版本控制工具