4

我一直在阅读Adam Dymitruk 的 git 工作流程，这一切都很有意义。

我找不到任何讨论的一件事是修复旧版本中的错误。用 7.0、7.1、7.2、7.3、7.4、7.4.1、7.4.2、7.8、8.2 和最新的 8.3 标记“master”分支

特定客户端的生产版本是 7.2，发现了一个错误，必须修复。

在 8.3.1 中修复它并将客户端从 7.2 移动到 8.3.1 是客户端无法接受的。

那么，是否有推荐的工作流程呢？

我可以从 7.2 标记创建主分支的一个分支，将此分支称为 release-7.2.x 然后，像对待主分支一样对待'release-7.2.x' - 从基线创建一个功能分支（72bug），修复 bug 等，最终将功能分支合并到“release-7.2.x”中，进行构建，制作 7.2.1 标签，并将其投入生产。'release-7.2.x' 将永远存在，就像 master 一样，因此可以在 release-7.2.x 上对 7.2.x 进行更多修复。

当然，人们不想丢失 7.2 对当前工作的修复，因此可以从当前主基线 (8.3) 创建一个特性分支，并将错误分支 (72bug) 合并到这个特性分支中。此功能分支将被视为当前发布周期/冲刺的任何其他功能。因此，在周期结束时，最新的基线 (8.4) 将包含错误修复。

其他人使用 Adam 的工作流程是如何解决这种情况的？

4

1 回答 1

0

如果您无法将客户端迁移到当前版本，那么真的没有办法从 7.2 标记开始一个新分支。

但是，我建议不要在 72bug 分支上修复错误并将其合并到 release-7.2.x 分支和当前功能分支中，而是在当前功能分支上修复错误，然后使用git cherry-pick将修复反向移植到release-7.2.x 分支。这将有助于保持您的历史干净，因此您当前的开发不会仅仅因为某个客户的需要而突然似乎依赖于旧版本。

于 2013-06-06T19:58:37.650 回答