git - 如何使用 GitFlow 模型处理两个主要版本

很长一段时间以来，我们一直在使用 GitFlow 模型和 feature/release/hotfix 分支。现在我们即将推出一个可能需要数周时间来开发的主要功能，并且会导致主要版本升级，我们希望保留这个主要功能的当前工作流程(因此不使用每个人都直接提交的单个分支)作为以及当前版本。

我想知道最好的方法是什么。是要 fork 整个 repo，然后 merge 回原来的吗？我们如何保持两个主要版本都处于积极开发状态，从而同时拥有 1.x 和 2.x gitflow 工作流程？

作为旁注，远程存储库托管在 github 上，因此将整个存储库 fork 到某个用户而不是组下，似乎有点违反直觉。

最佳答案

一般性评论只是为了向不熟悉 git flow 的用户澄清，
git flow 是一个开源软件，因此您可以修改流程并根据需要对其进行自定义

根据之前的评论，您有多种选择可以从这里开始:

正如你所建议的，github fork 是一个很好的解决方案。 git flow 在这种情况下有 support 分支，但此时它们被标记为实验性功能。
例如，github fork 将允许您使用 web-hooks 将更改从当前 dev 分支 merge/导出到您的并行分支。

修改 git 流以添加您在问题中需要的辅助流(“因此不使用每个人直接提交的单个分支”)，并且在提交这些更改时，您可以决定如何处理它，在哪里将其 merge 到基于在您的新 gitflow 分支类型上。

您需要记住并注意，如果您要进行“ 主要版本升级 您将不得不在途中“修复”很多冲突。

总结一下:
你可以选择使用 git flow，但是你必须确保你经常 pull 以避免以后发生巨大的冲突，当它们发生时立即修复它们
或者
您可以通过创建 2 个开发分支来修改 gitflow 并根据您的需要添加自定义，一个用于日常开发，第二个用于新产品开发线。提交到原始 dev 分支的所有更改也应该提交到新的 dev 分支，反之亦然。

关于git - 如何使用 GitFlow 模型处理两个主要版本，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/29751027/