Question

我们遵循基本的发布/主/功能分支模型

Master是主线
每个新功能都是在一个新的功能分支上开发的，该功能分支从master中分离并合并到master中，并且
当计划发布时，发布分支是由master创建的。

在发布分支后，如果在QA / UAT测试期间或发布后发现任何问题，我们会在发布分支本身上进行修复。我们如何确保每个此类修复程序也出现在master上？常见的建议是将发布分支合并为master。这听起来不错，但是如果发布分支上的修复不是绝对正确（比如由于时间限制而引入了hack）并且master有适当的修复，我们就不希望hack从发布中合并到master中科。关于如何解决这个问题的任何建议？

Answer 1

你应该根据发布创建一个新的分支，合并master，修改修复，然后通过混合分支发出拉取请求。

Answer 2

您可以通过不同方式处理此问题。我建议你在我每天使用的最常见的开源项目中使用分支模型/策略。

和你一样，主线是名为master的分支。 Master包含下一个版本。师父是你的发布分支。如果您使用的是42.43版本，则... mater包含从42.43.0到42.43的版本。*。其中*是路径/修复的数量。

现在，...假设有一个新版本要构建，有重大变化或一些巨大的重构。现在是时候创建分支42.43了，如果你没什么修改或43.0那么碰到版本42.44。

师父将是前者或后者。开发版本始终保留在mater分支中。旧的可维护版本留在他们的分支。

如何进行主要的开发修复？

假设有版本

master（您正在准备3.0.0版本）
2.4（以前的版本）
1.7（旧版）

如果你在1.7中发现了一个错误，那就从那里开始一个分支。可能你会有标签1.7.42。在1.7分支中，您正在构建1.7。*版本。只是......

从1.7开始分支
看看最新的标签（我使用git describe --tags求助）
修复次要版本
标记新路径1.7。（+ 1）

完成后，...只需将分支1.7合并到2.4。标记新的2.4。（+ 1）。并且直到主分支一样。

   -----*----* this is master
       /   /
 -----*----* this is 2.4
     /
----*-- this is 1.7

希望这有帮助

Git分支模型|合并主分支和发布分支

2 个答案:

如何进行主要的开发修复？