1

我正在尝试使用 Git 来管理产品的不同版本。我有几种方法可以做到这一点。我熟悉拥有“主”分支的概念，并沿着该主分支标记不同的点以构成解决方案的命名“版本”。例如，在某个时间点，我可能会决定当前构建代表我的产品的“RP_2012”构建。稍后，在添加更多功能后，可能会有“RP_2013”​​版本等。

我突然想到，即使开发可能在特定“版本”上完成，可能仍需要推出错误修复。例如，假设我在 Azure 中工作，每个客户都有自己的解决方案版本，而不是多租户安排（因为这样我就可以为他们提供更新版本的产品，如果他们想付费升级，并且他们可以继续使用他们熟悉的旧版本产品，直到他们准备好升级，而不是强加新功能）。我有一个使用 TeamCity、FluentMigrator 等组合的脚本，以便能够获取特定客户拥有的版本并随意升级它，同时保留他们现有的数据。所以，

如果我使用上面讨论的标记版本方法和单个“主”分支，那么推出这样的错误修复可能是不可能的。如果我改为为每个版本提供自己的分支，是否可以在派生自每个“版本”分支的祖先的单独分支中执行错误修复，然后将该分支合并为几个不同的、特定于版本的分支分支机构？或者是否有一些聪明的方法来使用 Rebase，这样如果我有一个会影响版本 10、11 和 12 的错误修复，比如说，那些“版本”只是沿着 master 分支标记的点，我可以从master 中标记为“版本 10”的点，并以某种方式将 master 重新设置为基于将在所述错误修复分支中完成的修复，从而确保版本 10 及更高版本都受益于给定分支地址的修复？与此同时，当然，任何新功能都将通过从 master 的 Head 中分支并合并回来完成。

我希望我的问题和潜在意图足够清楚。本质上，我想知道是否最好将给定产品的不同版本保留在一个主分支中。并且，如果是这样，如何最好地实施能够在需要时/如果需要时滚动到每个版本中的错误修复。这可能涉及将单个分支合并为几个离散的后代分支。或者它可能涉及重新定位所有版本所在的单个分支。或者也许你们知道一些更聪明的方法。

在此先感谢您的任何建议。

4

2 回答 2

2

我建议为此使用“git flow”。它是 git 的扩展，用于处理您所描述的用例，具有一个主分支和开发分支、单独的发布分支和单独的功能分支。有关所使用的分支模型的详细说明，请参阅这篇文章和这篇博文。

对于您所描述的目的，您应该非常小心地使用 rebase。Rebase 将重写版本历史，如果有来自具有“不同”版本历史的人的提交，这将变得非常混乱和困难。

于 2013-03-24T13:48:31.237 回答
1

我不认为有一个客观的方法来定义什么是最好的。

就我个人而言，我总是使用 1-branch-per-release 模型。特别是如果您有多个客户。有时甚至客户也会要求自定义功能，因此您从他们的分支分支分支以进行次要版本，依此类推。

在您的情况下，假设您使用多分支模型，并且您有一个要应用于某些分支的错误修复，您可以选择该修复/提交到任何需要它的分支。

另外，检查这个问题，提问者提供了一个同时提交多个分支的脚本。使用cherry-pick来解决这个问题。

于 2013-03-24T13:40:21.613 回答