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

每个客户都有自己的服务器。客户A使用1.0版本,客户B使用1.1版本,他们只需要热修复程序,不需要版本升级。这回答了你的问题吗?

对。你的手上有一个维护噩梦。我希望他们给你高薪。

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

在基本的Gitflow中,补丁程序从master上的最新版本标签分支出来。一旦完成,它们将被合并回主版本并标记以形成新的版本。它们也被合并回开发中,以将修补程序合并到未来的工作中。如果你一次只支持一个发布的版本,这很好。

要修补多个版本,您需要为每个受支持的旧版本创建一个分支。当你从v1.1迁移到1.2时,你会创建 support/1.1 关闭最后一个v1.1.x标签。

修补程序的开发方式与上述相同,但您也可以 重设基础 将其放入发布分支并标记结果。重新建立基础,而不是合并,因为你不想拖走所有其他新东西。

假设您在分支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中。

您对hotfix的定义与Git Flow的定义不同。例如,你想要的是支持分支 support/1.0 ,从标记的提交中分支出来 1.0 ,同时继续开发下一个版本。

在这个支持分支上,一旦对特定版本进行了更改,您就可以为每个版本启动该分支,并为该特定版本应用所谓的修补程序。如果主分支刚刚发布了2.0版本,并且必须在那里应用相同的修复程序,则它将成为一个Git Flow修补程序,完成后将合并回主分支(和开发),但不会合并回支持分支。

如果完全相同的更改适用于多个版本,则可以通过重基或cherrypicking将它们应用于每个支持分支。

在这个模型中,每个修补程序都应该被标记并合并到master中。

这听起来像是一个坏模型。修复程序需要应用于它们所应用的任何版本。 master (或任何其他分支)可能需要也可能不需要任何给定的修复。

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

但这可能意味着master上的时间会变得混乱,因为在标记了新版本后,一个修补程序会被合并到master上。。。?

修补程序应该精心挑选/重新调整。仅仅为了修复一个bug而将另一个版本的分支合并到master中是没有意义的。

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

作为对用户承诺的一部分,应将修补程序部署到您正在维护的任何软件版本上。如果你支持最新版本之后的三个次要版本,那么当漏洞或错误得到纠正时,你会向每个受支持的版本推送补丁。

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

例如:

如果我的最新版本是 2.3.0 ,我承诺在最新版本之后支持三个版本,我的用户会期望这些版本 2.2.x , 2.1.x ,以及 2.0.x 都将收到bug和漏洞补丁。

如果我提交了一个新的非关键补丁,这将使我的最新版本 2.3.1 ,其他一切都没有改变。

那么 假设发现了一个bug。我快速浏览一下,发现前三个次要版本的最新补丁是 2.2.9 , 2.1.12 ,以及 2.0.15 .

这三个过去的版本都有不同的git历史,因为它们接收了不同的功能和非关键补丁。但这并不意味着我不能单独对他们做出新的承诺。

有了这些信息,我将创建一个解决当前错误的提交,并将其推送到每个不同的分支。根据代码状态,我可能能够使用相同的提交并将其推送到所有分支。。。或者我可能需要为每个版本进行自定义。无论如何,我支持的所有三个过去的版本都将在我的最新版本旁边获得修补程序。

已收到修复程序的版本号为 2.3.2 , 2.2.10 , 2.1.13 ,以及 2.0.16

完成这项工作后,我现在设法兑现了对用户的承诺,即所有支持的版本都将收到错误和漏洞补丁。