处理并行版本时Git上的工作流

我们使用特性/错误修复的概念，在Git中开发和发布分支，我们不维护主分支

QA的构建和生产发布的最终构建取自发布分支，而快照取自开发分支

假设我们目前正在开发2个版本：

Release 1
Release 2

主要问题：合并从

release1

到

release2

的更改。在生产中部署

release1

之后，我们通常会进行大规模合并。这将导致多个合并冲突

防止这种情况的最佳工作流程是什么

我们的一个想法是将版本1的特性/错误修复分支合并到

release1

和

release2

的开发分支。尽管这将意味着开发人员需要做更多的工作。

从发布分支合并（git merge）通常不是最佳实践：一些提交只针对一个版本，不会应用于另一个版本

通常在不打算合并的两个分支之间完成（每个发布分支都有自己的独立历史）。
仍然会有冲突，但至少它们的起源更容易发现（它来自于所挑选的特定提交）。
同样的想法也适用于bug修复分支（并不是所有的修复都适用于下一个发行版分支，因此需要仔细挑选）。
但是可以合并功能分支。

从发布分支合并（git merge）通常不是最佳实践：一些提交只针对一个发布，不会应用于另一个发布

通常在不打算合并的两个分支之间完成（每个发布分支都有自己的独立历史）。
仍然会有冲突，但至少它们的起源更容易发现（它来自于所挑选的特定提交）。
同样的想法也适用于bug修复分支（并不是所有的修复都适用于下一个发行版分支，因此需要仔细挑选）。
但可以合并一个功能分支