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

Question

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

让我困扰的一件事是当部署在不同客户的不同版本应该获得修补程序时的问题。 在这个模型中，每个修补程序都应该被标记并 merge 到 master 中。

但这可能意味着 master 上的 timelime 变得困惑，因为一个修补程序将在 master 上 merge 之后一个较新的版本被标记......？

Answer 1

Each customer has his own server. Customer A uses version 1.0, customer Bversion 1.1 and they only want hot fixes, no version upgrades. Does that answer your question?

是的。您手上有一个维护噩梦。我希望他们能给你很好的报酬。

基本 Gitflow 支持在继续开发下一个版本的同时完成当前版本。它不支持同时修复多个版本。您将需要对其进行补充。

在基本的 Gitflow 中，修补程序从 master 上的最新版本标签分支出来。完成后，它们将 merge 回 master 并标记以形成新版本。它们也被重新 merge 到开发中，以将修补程序 merge 到 future 的工作中。如果您一次只支持一个已发布的版本，这会很好用。

要修补多个版本，您需要为每个受支持的旧版本创建一个分支。当您从 v1.1 移动到 1.2 时，您将在最后一个 v1.1.x 标记中创建 support/1.1。

修补程序的开发方式与上述相同，但您还需要将其 rebase 到发布分支并标记结果。 rebase ，而不是 merge ，因为您不想拖拽所有其他新内容。

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

这将仅将修补程序提交复制到每个发布分支。由于此代码是在较新版本的软件上编写的，因此很可能会发生冲突。随着您获得更多版本，冲突会变得更糟。

---

任何事情都比维护多个版本更可取。如果是我，在我做出 promise 之前，我会问为什么我的客户想要继续使用旧版本，以及他们是否值得花额外的时间和金钱。

通常是因为他们认为他们的版本是“稳定的”； 1.0 版适用于他们，他们看不到升级的必要，并且冒着出现错误和破坏他们所依赖的功能的风险。短期是明智的，但长期是灾难性的。随着他们越来越落后，当他们确实需要升级时，将变得越来越困难。

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

您可以为他们提供测试服务器，让他们用新版本试用他们的系统，这样他们就可以确定它能正常工作。

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