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

Question

我们一直在使用功能/发布/修补程序分支的GitFlow模型工作了很长时间。现在我们将要介绍一个可能需要数周时间才能开发的主要功能，并且将导致主要版本升级，我们希望保留当前这个主要功能的工作流程（因此不使用每个人直接提交的单个分支）以及当前的版本。

我想知道最好的办法是什么。它会分叉整个仓库然后合并回原始仓库吗？我们如何在主动开发中保持两个主要版本，同时具有1.x和2.x gitflow工作流程？

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

Answer 1

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

根据之前的评论，您可以选择如何从这里开始：

• 正如您所建议的那样，github fork是一个很好的解决方案。对于这种情况，git flow有support个分支，但此时它们被标记为实验性特征 github fork允许您使用web-hooks将当前dev分支的更改合并/导出到并行分支。

• 修改git流以根据问题的需要添加辅助流（＆＃34;因此不使用单个分支，每个人都直接提交＆＃34;）并且在提交这些更改时，您可以决定要做什么根据你的新gitflow分支类型，将它合并到哪里。

• 您需要牢记并注意，如果您要进行＆＃34; 主要版本升级，您将需要修复＆＃34;途中有很多冲突。

---

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

Answer 2

我也在这种情况下寻求答案，一段时间后，我找到了一种解决之道。

@CodeWizard提到：

通过创建2个开发分支来进行日常开发，一个分支用于您的新产品开发线。提交给原始dev分支的所有更改也应该也提交给新的dev分支，但反之亦然。

一种解决方法是让长期分支的行为像新的功能分支一样，例如feature/next-major-version。 当您需要下一个主要版本的新功能时，只需创建一个新功能分支。唯一的变化是它现在应该从feature/next-major-version分支出来，而不是像通常那样从develop分支出来。

要合并回子功能，只需将功能分支推送到GitHub，然后将子功能从您的子功能创建到feature/next-major-version中的拉取请求。如果适合您的需求，其他人可以查看您的代码。不过，在GitHub拉取请求中，允许您从任何分支合并到任何其他分支。

在我们的组织中，我们通过Atlassian出色的SourceTree程序使用git-flow。从那里可以像这样分支出来。面临的挑战是，到目前为止，SourceTree似乎不支持将功能合并到另一个功能中，而仅支持将功能合并到develop中。将GitHub拉取请求添加到工作流程即可解决此问题。