用于维护不同版本的Git分支模型

如何解决用于维护不同版本的Git分支模型

我最近阅读了很多关于不同分支模型的文章，并且总是以Vincent Driessen's结尾 是我的开发团队的最佳设置。

困扰我的一件事是当在不同客户处部署的不同版本应获得修补程序时出现的问题。 在此模型中，每个修补程序都应标记并合并到主修补程序中。

但这可能意味着master上的时间混乱了，因为一个新修补程序将在标记了新版本之后在master 上合并...？

解决方法

困扰我的一件事是当在不同客户处部署的不同版本应获得修补程序时出现的问题。在此模型中，每个修补程序都应标记并合并到主修补程序中。

您对修补程序的定义与Git Flow的定义不同。您想要的是支持分支，例如support/1.0，从标记为1.0的提交分支出来，同时继续开发您的下一个发行版。

在该支持分支上，您对该特定版本进行了更改后便会立即针对每个版本启动该分支，您可以应用该特定版本的所谓的修补程序。如果主分支仅具有2.0版本，并且必须在该分支上应用相同的修补程序，则它将成为Git Flow修补程序，该修补程序在完成后将合并回主（并进行开发），但不会合并回您的支持分支。

如果完全相同的更改适用于多个版本，则可以通过重新定级或挑选来将它们应用于每个支持分支。

,

每个客户都有自己的服务器。客户A使用1.0版，客户Bversion 1.1版，他们只需要热修复，而没有版本升级。可以回答您的问题吗？

是的。您手上有一场维护噩梦。我希望他们能给你很好的工资。

Basic Gitflow支持完成当前版本，同时继续开发下一个版本。它不支持同时修复多个版本。您将需要补充它。

在基本的Gitflow中，修补程序会分支出master上的最新版本标签。完成后，它们将合并回master并进行标记以形成新版本。它们也被合并回开发中，以将修补程序合并到将来的工作中。如果您一次仅支持一个发行版本，则此方法很好。

要修复多个发行版，每个较旧的受支持发行版都需要一个分支。从v1.1移至1.2时，您将在最后一个v1.1.x标签上创建support/1.1。

修补程序的开发方法与上述方法相同，但是您也可以将其变基到发布分支中并标记结果。重新设置基础，而不是合并，因为您不想拖延所有其他新内容。

假设您在分支hotfix / 123上对v1.2进行了修复。现在，您要将其应用于v1.1和v1.0。

# Copy the hotfix commits to support1.1
# Tag it as v1.1.1
git rebase --onto support/1.1 v1.2 hotfix/123
git tag v1.1.1 support/1.1

# Copy the hotfix commits to support1.0
# Tag it as v1.0.1
git rebase --onto support/1.0 v1.2 hotfix/123
git tag v1.0.1 support/1.0

这将仅将修补程序提交 复制到每个发行分支。由于此代码是在较新版本的软件上编写的，因此可能会发生冲突。随着版本的增加，冲突会越来越严重。

---

任何事情都比维护多个版本更可取。如果是我，在我致力于这一点之前，我会问为什么我的客户希望保留旧版本，以及他们是否值得额外的时间和金钱。

通常是因为他们认为自己的版本“稳定”； 1.0版适用于他们，他们不需要升级，也不必冒险依靠其依赖的错误和破坏功能。短期明智，但长期而言却是灾难性的。随着它们越来越落后，当他们确实需要升级时，它将变得越来越困难。

有时可以想象这种稳定性观点，有时是真实的。 Regression testing可以确保每个新版本都不会破坏现有功能。您甚至可以对客户进行调查，以找出他们特别依赖的功能，并确保它们经过了良好的测试。

您可以为他们提供测试服务器，以尝试使用新版本的系统，以便他们确定它可以正常工作。

最后，作为企业，请问支持旧版本是否值得。

,

在此模型中，每个修补程序都应被标记并合并到主修补程序中。

听起来像是坏了的模型。需要将修补程序应用于它们所适用的任何版本。 master（或任何其他分支）可能需要也可能不需要任何给定修复程序。

此外，“标记此修补程序”没有任何意义。标签是提交的名称，而不是补丁/差异的名称。

但这可能意味着master上的时间混乱了，因为标记了新版本后，一个修补程序将在master上合并...？

修补程序应该经过精心挑选/重新定型。仅仅为了修复错误，将另一个版本的分支合并到master中是没有意义的。

,

以下并不是每种方法的详尽解释，但它应该回答问题的核心。如果有人提出改进建议，我会很乐意修改。

应将修补程序部署到您维护的任何软件版本中，这是对用户的承诺。如果您支持最新的三个次要版本，则在纠正漏洞或错误后，将向每个受支持的版本推送补丁。

但是，新功能和非关键补丁只会用于您的最新版本。

例如：

如果我的最新版本为2.3.0，并且我已承诺支持最新的三个版本，则我的用户将期望使用2.2.x，2.1.x和2.0.x版本都会收到错误和漏洞补丁。

如果我提交了一个新的非关键补丁程序，那么它将我的最新版本设置为2.3.1，并且其他任何更改都没有。

然后可以说发现了错误。我快速浏览一下，发现前三个次要版本的最新修补程序是2.2.9，2.1.12和2.0.15。

这三个过去的版本都具有不同的git历史记录，因为它们接收不同的功能和非关键的补丁程序。但这并不意味着我不能单独对它们进行新的提交。

结合这些信息，我将创建一个解决当前错误的提交，并将其推送到每个不同的分支。根据代码状态，我也许能够使用相同的提交并将其推送到所有分支...或者我可能需要针对每个版本对其进行自定义。无论如何，我支持的所有过去三个版本都将在我的最新版本中提供该修补程序。

已收到此修复程序的版本号为2.3.2，2.2.10，2.1.13和2.0.16

完成此操作后，我现在已经对用户承诺，所有受支持的版本都将收到错误和漏洞补丁。