リリースブランチの管理方法

Question

gitを使用して複数のリリースブランチを管理しようとしています。私たちの支店組織は典型的です。主な進行中の開発はマスターです。トピックブランチは作業に使用され、マスターにマージされます。マスターは次のメジャーリリースです。ただし、暫定リリース（ドットリリース）についても取り組んでいます。たとえば、7.3.2で作業している間に、masterはバージョン7.4に向けて作業します。

もちろん、7.3.2で行われた作業の大半（すべて？）は7.4でなければなりません。 7.3.2リリースブランチで行われた作業の大半は、マスター（つまり7.4）リリースブランチに対しても実行する必要があります。

これらのブランチを管理するために使用する技術は何ですか？特に、変更が両方のブランチにマージされるようにしますか？

私たちのソリューションは、並列トピックブランチを作成することでした。リリース・ブランチのいずれかでトピックが完了すると、cherry-pickまたはrebase --ontoを使用して別のトピック・ブランチにコピーされます。また、手動でdiffおよびマージすることもあります。

このプロセスでは、メカニックが対象です。他の人はどのようにしてメカニックが実際に発生することを保証しますか？両方（多くの）リリースブランチに変更が加えられたことをどのように確認しますか？ご提案

Answer 1

我々はこのブランチあたりの機能ワークフローを使用するための

ありがとう：

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

何もメジャーリリースごとに同じことをやってからあなたを停止しています。コメントがあれば、またはGoogle+チャットで直接お気軽にお問い合わせください。

Answer 2

あなたが期待するプッシュ数にもよりますが、私たちはGit reposをTracとチケットシステムに接続しています。コミットメッセージを強制的に特定のフォーマットに従うように強制するGit用のカスタムフックを書いています（チケットを引用するなど）。 Tracはコミットメッセージをチケットに投稿して残りの部分を処理します。チケットの参照はありません。プッシュは拒否されます。だから絶対にすべてのチケットに関連付けられている必要があります。

また、チケットの変更を複数の人にメールで送信しました。プッシュが来て、それが他のものに行くべきであるときに1つの支店だけに行くならば、チケットモニタの1人（OCDを持つ上級開発者）は、プッシュを行った人を開いて、適切な支店。

コミットが異なるブランチでどのように終わるかの仕組みは、開発者次第です。チェリーピッキング、レベリング、他のパッチのようなものもあります。私はコミットが必要なすべてのブランチがそれを取得する限り、そこにどのように到達するか気にしない！