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

Question

我试图弄清楚我是否能够利用修改后的 gitflow Git 工作流程，但我正在努力解决它（不确定它是否相关，但计划使用 Atlassian Stash）：

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

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

master：目前正在生产什么

develop：下一个生产版本的开发分支，将与下一个版本一起发布的项目分支将在这里合并，以及未发布到较大项目的小功能（新功能和生产错误修复）

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

feature/ticket_no：功能分支，从开发分支出来，用于较小的非项目功能。从 project/project_name 分支出来，用于更大的项目。

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

bugfix/ticket_no：bugfix 分支，从 release/release_number 分支分支出来，用于 QA 发现的错误。合并回 release/release_number 并开发。

hostix/ticket_no：紧急生产问题的修补程序。从master分支出来。合并到 master、develop 和 release 分支。

这听起来可行吗，还是因为会出现巨大的合并复杂性，我会在这里自欺欺人？对替代方法有什么建议吗？

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

Answer 1

您描述的工作流程听起来与我在最近工作过的两家商店所看到的非常相似。 Git 的伟大之处在于创建一个新分支的成本并不高。因此，虽然在 CVS 中创建如此多的分支可能会带来巨大的损失，但在 Git 中，您会发现可以在几分钟内创建整个工作流程。

您提到了 Atlassian Stash，值得一提的是，这是指您计划使用的 存储库。存储库是您的团队将存储来自所有分支的提交的（通常是远程的）位置。 Git 就是 Git，无论您使用 GitHub、Stash、BitBucket 还是任何其他存储库，您所拥有的功能都不会因 repo 而改变。但是，repo 通常会添加一些工具来简化远程分支的管理。作为企业级repo，Stash在这方面表现突出，应该可以处理你的用例。

话虽如此，您在使用 Git 时不一定会遇到更少的合并冲突。在 Git 中让多个开发人员解决单个合并冲突并不常见。

作为一个侧面说明，Git 不能很好地处理开箱即用的二进制文件。因此，如果您当前的 CVS 存储库中充满了二进制文件，那么您将需要在采用 Git 之前查看所有版本控制工具。