目前使用http://nvie.com/posts/a-successful-git-branching-model/效果很好。
我不太清楚的一点是如何处理在创建发布分支时完成的修复。
如果它是一个常规的修补程序，我会从 master 分支，完成修复，然后合并到 master 和 release。但是，如果它是要合并到我当前版本中的修复，我是从发布分支分支然后与合并对象合并回来还是只修复发布分支上的错误？我是否会为在发布分支上完成的每个修复增加版本号？
问问题
1148 次
1 回答
1
我不太清楚的一点是如何处理在创建发布分支时完成的修复。
根据Git Flow模型，修补程序
源于对现场制作版本的不良状态立即采取行动的必要性。
如果在处理发布分支时，您非常需要一个修补程序（例如高安全风险）以至于您无法等待发布分支完成，Git Flow 规定您执行以下操作：
此处规则的一个例外是，当当前存在发布分支时，需要将修补程序更改合并到该发布分支中，而不是
develop. 当发布分支完成时，将错误修复反向合并到发布分支最终会导致错误修复也被合并到develop。（如果develop立即工作需要此错误修复并且不能等待发布分支完成，您也可以安全地将错误修复合并到developnow 中。）
（感谢您对此进行纠正；我完全忘记了那个例外。）
但是，如果它是要合并到我当前版本中的修复，我是从发布分支分支然后与合并对象合并回来还是只修复发布分支上的错误？
据我了解，既然你写了
[如果] 这是一个常规的修补程序 [...]
有问题的修复不是很紧急，也不符合修补程序的条件。在那种情况下，为什么不直接在发布分支上做呢？毕竟，根据Git Flow模型，这就是发布分支的用途：
发布分支支持准备新的生产版本。它们允许在最后一分钟点 i 和交叉 t。此外，它们允许修复小错误并为发布准备元数据（版本号、构建日期等）。
我是否会为在发布分支上完成的每个修复增加版本号？
不，版本号在发布分支创建后立即确定。在后者上修复某些内容不应导致该版本号发生更改。
于 2014-09-11T06:24:32.750 回答