トランクからブランチへの変更をマージするのを忘れている
最近、トランクからメンテナンスブランチへの変更をマージするのを忘れました。これにより、再構築が2回行われ、混乱を修正する間、QAが2日間保留になりました。
通常、両方のブランチにコミットするときは、単一のチェンジセットをトランクにコミットし、すぐにそれをメンテナンスブランチにマージします。
しかし、今回は多くのコードレビューの変更にまたがる12の変更セットがあり、すべての変更をマージできませんでした。私は1つの変更をマージしただけで、完全に失望しました-それは他のすべての変更セットのロールアップコミットであることを覚えていると思いましたが、そうではありませんでした。
開発について話し合った結果、1対1のトランクとメンテナンスブランチをコミットするのが最善の方法であると判断しました。これにより、すべてのコードがそこにあることを視覚的に確認できます。
特定の修正バージョンに対してチェンジセットコミットを強制する方法はありますか？
[〜＃〜] jira [〜＃〜] 、 Fisheye 、および Crucible を使用すると、Fisheyeワークフローが勝ちましたコードレビューが完了しない限り、問題を解決することはできません。問題で指定されている修正バージョンに基づいて、トランクブランチとメンテナンスブランチに並列チェックインを強制するようなものが欲しいのですが。
それとも、「それをしない」以外に、この混乱全体に対するより良い解決策はありますか？
明らかに、これはgitを使用する場合にのみ機能しますが、これが私がそれにアプローチする方法です...
各機能リクエストと各バグは、ローカルで独自のブランチを取得します。その後、開発者は必要なすべての変更を行います。それらが完了したら、ブランチをリベースし、コミットを論理ワークユニットにマージ/分割します。小さな機能やバグ修正の場合、これを1回のコミットで維持するのは難しいことではありません。より大きな機能の場合は、複数のコミットが必要になる場合があります（例：「fooのインターフェースを追加」）。 「fooの実装を追加する」。 「Whizbangに新しいfoo機能を使用させます」。重要なのは、論理的に接続されたすべてのコード行を1つのコミットに保持することです。その時点で、ワークユニットには1つ（またはセット）のコミットがあります。バグトラッカーを使用すると、コミットをチケットにリンクできます。バグ修正チケットはバグ修正コミットにリンクし、コミットが適切なリリースブランチにマージされたことを簡単に確認できるはずです。
あなたがしたことは、それが実際に行われたことを追跡せずに、それを行うことを覚えておく必要がある（したがって、すぐに行う）プロセスの欠陥の結果である可能性があります。
質問：すべてのマージが完了したことを確認するレポートを簡単に作成できますか。もしそうなら、単一のアクションの単一の個人による失敗がレポートを不正確にする可能性があります（つまり、プロセスに単一点障害モードがありますか）？
実際には2つの変更が必要です。 1つはメインブランチへの配信で、もう1つはメンテナンスブランチへの配信です。 Jiraを使用して、これらを2つの関連する配信として追跡します。
これには、マージを必要なメンテナンスに延期し、延期された内容を確認できるなどの利点がありますが、オーバーヘッドがあります。また、これらを記録および報告する方法によっては、管理者への報告システムが実際に持っているより多くの欠陥を報告する可能性があります。
私の仕事では、プロジェクトの開始/終了に役立つ自家製のソフトウェアがあります。プロジェクトを着陸させると、ツリーが作成され、変更が適用されてから、トランク内の変更がマージされます。 （そこで競合を解決します。）終了すると、競合がコミットされます（そしてプロジェクトが削除されます）。
プロジェクトを開始するときに、それが修正プログラムであるかどうかを指定します。ホットフィックスの場合は、着陸するとトランクとメンテナンスブランチの両方にパッチが作成されます。
もちろん、プロジェクトを修正プログラムにすることを忘れないでください。ただし、関連する多くの変更がすべて、必要な場所で一緒にコミットされるようにするのは簡単です。