如何管理发布分支答案

【问题标题】：How to manage release branches如何管理发布分支
【发布时间】：2012-01-22 05:14:34
【问题描述】：

我们正在尝试使用 git 管理多个发布分支。我们的分支组织是典型的。主要正在进行的开发是在主人身上。主题分支用于工作并合并到 master。 Master 是下一个主要版本。但是，我们也致力于临时版本（点版本）。例如，master 将致力于版本 7.4，而我们也在开发 7.3.2。

当然，为 7.3.2 完成的大部分（全部？）工作必须在 7.4 中完成。也就是说，为 7.3.2 发布分支所做的大部分工作也必须为 master（即 7.4）发布分支完成。

您使用哪些技术来管理这些分支？特别是，确保将更改合并到两个分支中？

我们的解决方案是创建并行主题分支。一旦一个主题在一个或另一个发布分支上完成，它就会从另一个发布分支复制到另一个主题分支，使用cherry-pick 或rebase --onto，有时甚至是手动差异和合并。

这个过程涵盖了机制。其他人如何确保机制实际发生？您如何验证对两个（许多）发布分支都进行了更改？

感谢您的建议

【问题讨论】：

标签： git version-control

【解决方案1】：

我们使用这个按功能分支的工作流程：

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

没有什么能阻止您在每个主要版本中做同样的事情。如果您需要更清晰的信息，请随时通过那里的 cmets 或直接在 Google+ 聊天中与我联系。

【讨论】：

google+ 链接已失效，因为 google 放弃了它。

【解决方案2】：

这取决于您期望的推送次数，但我们将 Git 存储库连接到 Trac 和那里的票证系统。我们为 Git 编写了一些自定义钩子（如果你愿意，我可以分享），它们强制提交消息遵循特定格式，包括引用票证。 Trac 通过在票证上发布提交消息来处理其余部分。没有票证参考，推送被拒绝。所以绝对一切都必须有一张与之相关的票。

我们还将机票更改通过电子邮件发送给了几个人。如果推送进来并且只在一个分支上进行，而它也应该在其他分支上继续，那么其中一个工单监视器（他们是患有强迫症的高级开发人员）将去重新打开/纠缠进行推送的人，直到它出现在所有分支上相应的分支。

提交最终在不同分支上的机制取决于开发人员。有些喜欢樱桃采摘，有些喜欢变基，有些喜欢补丁。我不在乎它是如何到达那里的，只要所有需要提交的分支都得到它！

【讨论】：