リリースブランチのマージで現れるバグ
gitflowモデル をたどろうとすると、リリース用のブランチがあります。ただし、開発からマージしようとすると複雑なマージが発生し、そこからバグがそのブランチに侵入しました。
何が間違っているのでしょうか。また、これらのマージバグが表示されないようにするにはどうすればよいですか。
私たちのgitツリーは次のようになります：
d r m
| | |
o | |
|\ | |
| \| |
| 1 |
o | |
| 2 |
| | |
o 3 |
| /|\ |
|/ | \|
o | 4
|\ | |
| \| |
| 5 |
ここで、oは開発ブランチの変更です。 1は、開発ブランチがリリースにマージされた場所です。2および3はリリースブランチのバグを修正するためのコミットであり、次に4はマスターでのリリースです。その後、これは5開発がリリースブランチに再びマージされます。
各ブランチには、その役割、つまり目的があります。存在するその全体的な理由。その目的が完了したら、ブランチを閉じてさらに変更し、メインラインにマージして戻す必要があります。
永続リリースブランチがあるということは、ブランチの目的が完全ではないことを意味します。これは、ブランチが永続的に変更に対して開かれているためです。新しいリリースがあるたびに、開発ブランチからリリースブランチにマージしていることに気付くでしょう。そして、これはアイデアの融合ではありません。リリースブランチの状態を、現在の開発作業責任者に完全に置き換えるものです。それがではない開発からのコードの状態の完全な置き換え（理論的にはリリースの準備ができている）の場合、リリースブランチとの間で異なるバグが忍び寄る場所を提供します開発ブランチ。
マージではなく状態の完全な置換は、古いブランチが完了したことを明確に示唆しており、これは新しいブランチです。これをすべての人に明確にするために、ここに別のリリースブランチがあります。
進行中の2つのリリースがある（ありそうもない）状況も考慮してください同時に。リリース作業には2か月かかります（認証、テスト、さらにテスト、そのリリース作業で発生するバグの修正、再認証、さまざまなビルドのパッケージ化）。そして今、1か月後、anotherリリース作業が開始されますnextリリース。これは別の目的、つまり別のブランチです。
または、リリースブランチがあり、展開するプラットフォームごとにブランチする状況を考えてみます（Mac、Windows、およびUnixシステムで適切に機能するように調整します）。また、リリース1.0はWindowsのドアの外にあるかもしれませんが、MacとLinuxの取り組みにはもう少し時間がかかります（1.1リリースの準備ができている間）。繰り返しますが、これらはそれぞれ個別のリリースと個別のブランチです。
ブランチに関する私のお気に入りのホワイトペーパーの1つは、 Advanced SCM Branching Strategies のホワイトペーパーです。これはPERFORCE（当時の集中型バージョン管理システム）に焦点を当てていますが。それが提唱する概念は、git-flowモデルに明確にマッピングできます。
このホワイトペーパーでは、パッケージ化の役割はgit-flowリリースブランチにマップする役割です。
パッケージングの役割は、蓄積、またはより一般的にはメインラインの役割と混同されることがよくあります。目的の開発と保守が実行され、蓄積が行われたら、リリース用のコードを準備します。このような作業は簡単ではない場合があり、リリースエンジニアのチームと、すでに実行されているもの以外の追加の修正が必要になります。パッケージングの役割が示唆するように、パッケージングブランチのポリシーは、メンテナンスブランチのポリシーとは大幅に異なり、製品をリリース可能にするために必要な変更のみに対処する必要があります。
製品のパッチレベルを作成する場合に発生する可能性が高いように、他の製品ブランチで作業を進める場合、リリース作業が次のパッチレベルに向けて進行を遅らせることは望ましくありません。他のパッケージング分岐戦略では、マイナーバージョンが同じメインラインから実行され続ける可能性があり、パッケージングアクティビティの実行中にストールが発生する可能性が高まります。
別のブランチを使用して、リリース作業を進行中の開発および保守から隔離することをお勧めします。その逆も同様です。マルチプラットフォーム環境では、最終的な移植作業のために、プラットフォームごとに1つのパッケージングブランチを作成することをお勧めします。移植作業がずらされている場合、これにより、ずらされたリリースをバージョン階層に反映させることができます。移植作業が同時に行われる場合は、プラットフォームごとのパッケージをマスターパッケージブランチに蓄積し、そこから最終ビルドを実行することも検討する必要があります。マスターパッケージングブランチから個別のパッケージングブランチを作成するのが最適であるため、これは事前に決定する必要があります。
これが、リリースブランチをメインラインブランチから分離する理由であり、リリースブランチを互いに分離する理由でもあります。