本当にmasterブランチが必要ですか、それともリリースブランチから直接リリースできますか？
現在、次のブランチがあります。
- 発展させる
- リリース1
- リリース2
- 等..
- 主人
リリースの新機能を切り離したい場合は、新しいリリースブランチ（リリース3など）を作成します。その後、バグ修正などをリリースブランチにのみ適用し、大きな変更は行いません。
リリース3がテストされ、すべての準備が整ったら、リリース3をそれ以上の変更からロックダウンし、それをマスターにマージして、リリースマスターを本番環境にマージします。
私の質問は本当にマスターブランチが必要ですか？なぜリリース3から製品版に直接リリースできないのですか？.
最初にマスターにマージすると、リリース3からマスターへの「不良」マージを行わないようにするために、作業とリスク/テスト要件が追加されるだけです。
私の見解から認識されているもう1つのメリットは、リリース3ブランチから直接リリースすることです。これは、何かがひどくうまくいかず、ロールバックすることにした場合、リリース2ブランチを本番環境に再リリースして、リリース3の修正を続行できることを意味します。これは、マスターをロールバックする必要があるよりも簡単に思えます。
私はこれを調べてみましたが、リリースブランチとマスターブランチの違いについての情報しか見つけられませんでした。
編集：通常、複数のリリースブランチを保持する理由は、テストフェーズの準備ができた2つ以上の「リリースに値する」開発セットが作成されることが多いためです。例えば。テストチームはリリース1に取り組んでいる可能性があり、開発はリリース2の作業を終えたところです。リリース2とリリース1を一緒にマージすることは望ましくありません。これにより、テストフェーズが効果的に再開され、リリースが延長されます。したがって、代わりにリリース2の作業用に新しいリリースブランチを作成します。
本当にマスターブランチが必要ですか？
これは構造的/命名的なことだと思います。リリース時のリリースとマスターブランチは同じであるようです。これは、リリースには不要であることを意味します。
プロジェクトでは、標準的な方法とは少し異なる方法でブランチを使用しているようです。名目上、master/releaseブランチがあり、リリースにはタグが付けられます。開発者はブランチを作成して機能や修正などを追加し、ブランチをマスターにマージしてリリースに使用できるようにします。
次に、古いリリースに適用する必要があるバグが発生すると、タグ付けされたバージョンに基づいてそのリリースに新しいブランチが作成され、バグ修正が行われ、マージされ、何があり、次に新しい古いバージョン（ポイントリリース）が作成されます。 ）はまだ古いリリースを使用している人のために作られています。
修正を古いリリースにロールバックするつもりがない場合、または単に修正をサポートしない場合は、修正はまったく必要ありません。したがって、通常の方法でオンデマンドで修正を作成すると、プリエンプティブに作成したように見えます。したがって、あなたの場合、Noマスターブランチは本当に必要ありませんが、変更をプルする必要があるまで、リリースブランチは本当に必要ないようです。
ある程度、好きなようにできます。私の場所では、鉄のルールが1つあります：gitにあるもの（開発者のマシンではない）をリリースしてタグを付けるので、数年以内にその正確なコードを再び取得できます。それは決して破ってはならない一つのルールであり、他のすべては二次的です。
二次的なもの：特定の時点で、リリースブランチをマスターブランチにマージします。これは非常にまれであり、競合なしに実行する必要があります。好きなようにできます。
あなたがマスターブランチを持っている理由に依存します。 git diffマスターと最新リリースの違いを確認してください。それを理解すれば、それを取り除くために何を変更する必要があるかを理解できます。
たとえば、マスターブランチとリリースブランチの違いは、本番クレデンシャルがマスターブランチで維持されることです。その場合、本番環境でのみこれらの認証情報を追加する別の方法がないと、masterブランチを削除できません。