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

我最近读了很多关于不同分支模型的文章，最后总是以 作为我的开发团队的最佳设置

困扰我的一件事是，部署在不同客户的不同版本应该得到修补程序。 在这个模型中，每个修补程序都应该被标记并合并到主程序中

但这可能意味着主机上的时间被弄乱了，因为在一个较新的版本被标记后，一个修补程序将被合并到主机上

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

这听起来像是个坏模型。修复程序需要应用于它们应用于的任何版本<代码>主机（或任何其他分支）可能需要也可能不需要任何给定的修复

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

但这可能意味着主机上的时间被弄乱了，因为在一个较新的版本被标记后，一个修补程序将被合并到主机上

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

困扰我的一件事是，部署在不同客户的不同版本应该得到修补程序。在这个模型中，每个修补程序都应该被标记并合并到主程序中

您对修补程序的定义与Git Flow的定义不同。您需要的是支持分支，例如

support/1.0

，它是从标记为

1.0

的提交分支出来的，同时继续进行下一版本的工作

在这个支持分支上，当您对某个特定版本进行更改时，您就可以为该特定版本应用所谓的修补程序。如果主分支刚刚发布了一个2.0版本，并且必须在那里应用相同的修复程序，那么它将成为一个Git Flow热修复程序，完成后会合并回主分支（并进行开发），但不会合并回您的支持分支

---

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

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

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

但是，新功能和非关键修补程序将仅适用于您的最新版本

例如：

如果我的最新版本是

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历史，因为它们接受不同的特性和非关键补丁。但这并不意味着我不能单独对他们做出新的承诺

有了这些信息，我将创建一个解决当前bug的提交，并将它推送到每个不同的分支。根据代码状态，我可能能够使用相同的提交并将其推送到所有分支。。。或者我可能需要为每个版本自定义它。不管怎样，我支持的所有三个过去版本都将与我的最新版本一起获得修补程序

已收到修复的版本号为

2.3.2

、

2.2.10

、

2.1.13

和

2.0.16

这样，我现在就成功地向用户承诺，所有受支持的版本都将收到bug和漏洞补丁

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

对。你手上有一个维护噩梦。我希望他们能给你丰厚的报酬

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

在基本Gitflow中，修补程序在master上分支出最新版本标记。一旦完成，它们将合并回主版本并标记为新版本。它们还被合并回develope，以便将修补程序合并到未来的工作中。如果您一次只支持一个发布的版本，那么这很好用

要热修复多个版本，您需要为每个较旧的受支持版本提供一个分支。当您从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

这将仅将热修复程序提交复制到每个发布分支。由于此代码是在较新版本的软件上编写的，因此可能存在冲突。当您获得更多版本时，冲突将变得更严重

---

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

通常是因为他们认为他们的版本