我正在尝试使用Git来管理产品的不同版本。我有几种方法可以做到这一点。我熟悉拥有“主”分支的概念，并在主分支上标记不同的点以构成解决方案的命名“版本”。例如，在某个时间点，我可能会认为当前版本代表了我产品的“RP_2012”版本。稍后，在添加了一些更多功能之后，可能会有“RP_2013”版本等。
我发现即使开发可能在特定的“版本”上完成，仍可能需要推出错误修复。例如，假设我在Azure工作，每个客户都有他们自己的解决方案版本，而不是多租户安排（因为这样我就可以为他们提供更新版本的产品，如果他们想付钱给他们升级，他们可以使用他们感觉舒适的旧版本产品，直到他们准备升级而不是强加给他们的新功能）。我有一个脚本，它使用TeamCity，FluentMigrator等的组合，能够获取特定客户的版本并随意升级，同时保留他们现有的数据。因此，虽然正在添加到产品中的任何新功能将在他们自己的分支上创建，然后合并到主服务器的头部以便在将来的某个版本中发布，但是还需要有可能应用于错误修复的范围。当前正在使用/支持的产品的任何/所有版本。
如果我使用标记版本方法和单个“主”分支，如上所述，可能无法推出此类错误修复。如果我改为为每个版本提供自己的分支，是否可以在从每个“版本”分支的祖先派生的单独分支中执行错误修复，然后将该分支合并为几个不同的版本特定的版本分支机构？或者是否有一些聪明的方法来使用Rebase，以便如果我有一个错误修复，将影响版本10,11＆amp; 12，比方说，那些'版本'只是在主分支上标记了点，我可以从主程序中标记为“版本10”的点分支出来，并且以某种方式基于将在所述的修复中进行修改错误修复分支，从而确保版本10及更高版本都受益于给定分支地址的修复？当然，与此同时，任何新功能都可以通过分支并合并回主人头来完成。
我希望我的问题和潜在意图足够明确。 从本质上讲，我想知道是否最好在一个主分支中保留给定产品的不同版本。并且，如果是这样，如何/如果需要，如何最好地实现能够在每个版本中滚动的错误修复。这可能涉及将单个分支合并到几个离散的后代分支中。或者它可能涉及对所有版本所在的单个分支进行重新定义。或者你们可能知道一些更聪明的方式。
提前感谢任何建议。
答案 0 :(得分：2)
我建议使用“git flow”。它是git的一个扩展，用于处理您正在描述的用例，包括一个master和develop分支，单独的发布分支和单独的功能分支。有关所用分支模型的详细说明，请参阅this和this博客文章。
对于您描述的目的，您应该非常小心使用rebase。 Rebase将重写版本历史记录，如果来自具有“不同”版本历史记录的人提交，将使其变得非常混乱和困难。
答案 1 :(得分：1)
我认为这里没有客观的方法来定义 best 。
就个人而言，我总是使用每分支1分支模型。特别是如果你有多个客户。有时即使是客户端也会要求自定义功能，因此您需要从其分支机构进行分支以进行次要发布，依此类推。
在您的情况下，假设您使用多分支模型，并且您想要应用于某些分支的错误修复，您可以cherry-pick修复/提交到需要它的任何分支。
另外，检查this question，提问者提供了一个脚本，用于同时提交多个分支。使用樱桃挑选。