我们正在尝试使用git管理多个发布分支。我们的分支机构是典型的。主要的持续发展是掌握。主题分支用于工作并合并为主。 Master是下一个主要版本。但是，我们也在处理临时版本（点发布）。例如，master将致力于7.4版，而我们也在研究7.3.2。
当然，7.3.2所做的大多数（全部？）工作必须是7.4。大多数情况下，7.3.2发布分支的工作也必须为主（即7.4）发布分支完成。
您使用哪些技术来管理这些分支？特别是，确保将更改合并到两个分支中？
我们的解决方案是创建并行主题分支。在一个或另一个发布分支上完成主题后，使用cherry-pick或rebase --onto或有时甚至手动差异和合并将其复制到另一个发布分支的另一个主题分支。
这个过程涵盖了机制。其他人如何确保机制实际发生？您如何验证是否已对两个（许多）发布分支进行了更改？
感谢您的建议
答案 0 :(得分：1)
我们使用这个按功能分支的工作流程：
https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
没有什么能阻止你在主要版本中做同样的事情。如果您需要更清晰，请随时通过此处的评论或直接在Google+聊天中与我联系。
答案 1 :(得分：0)
这取决于您期望的推送次数，但我们将Git回购连接到Trac和那里的票务系统。我们已经为Git写了一些自定义挂钩（我可以分享，如果你愿意的话）强制提交消息遵循特定的格式，包括引用票证。 Trac通过在票证上发布提交消息来处理剩下的事情。没有票证参考，推送被拒绝。所以一切都必须有一张与之相关的票。
我们还通过电子邮件将票证更改发送给了几个人。如果推送进入并且只在一个分支上进行，当它应该继续进行其他分支时，其中一个票证监视器（谁是具有强迫症的高级开发人员）将重新打开/纠缠推动的人，直到它出现在所有适当的分支。
提交如何在不同分支上结束的机制取决于开发人员。有些人喜欢樱桃挑选，有些人喜欢调整，有些则是补丁。只要所有需要提交的分支都得到它，我就不在乎它是如何到达那里的！