Gitフローを簡素化するために開発ブランチを取り除く方法

継続的に開発されたWebプロジェクト（製品ではない）には、現在gitフローにほぼ基づいた次の分岐戦略があります。

• 開発ブランチ：最新の作業バージョン
• マスターブランチ：リリースされるバージョン/リリースされるバージョン
• 機能ブランチ：開発中の機能
• ホットフィックスブランチ：リリースバージョンの緊急バグ修正

マスターは読み取り専用で、開発ブランチまたはホットフィックスブランチからのプルリクエストによって更新されます。各更新により、リリース候補が構築され、ステージングシステムに展開されます。リリース候補は、手動の承認後に実稼働に展開されます。

フィーチャーブランチはオフに基づいて作成されている開発、または最後のマスターにマージされたことにコミットから。開発する機能ブランチからのプルリクエストが構築され、統合テストと受け入れテスト（自動および手動）が実行される無料のテストシステムにデプロイされます。テストとレビューに成功すると、PRはマージされ、次のリリースの一部になります（開発からマスターへのマージ）。

私の目標

これを簡素化し、開発ブランチを削除したいと思います。開発ブランチには主に歴史的な理由があり、常に正常にテストされたバージョンであるため、マスターから切り離しておく必要はないと思います。これを削除すると、追加のマージがなくなるため、リリースプロセスも簡素化されます。

次の制約があります。

• リリースは予定されており、完全に自動化するべきではありません
• 機能ブランチは通常短命ですが、一部は数週間マージされないままになります（たとえば、再設計）が、同様にテストする必要があります（現在、開発のためのオープンプルリクエストとして）
• 場合によっては、通常のリリース以外で単一の機能をリリースして、事実上それを修正プログラムに変更する必要があります。現在の戦略では、機能ブランチをリベースし、直接マスターにマージできます
• ステージングでの外部システムとの受け入れテストが失敗した後、機能を保留する必要があることも起こります

移行についてわからない場合：

• 現在、テスト用のプルリクエストを作成し、リリース用のコミットをマージしています。これを統合できますか？
• マスターが最新リリースより前である場合のホットフィックスの処理方法。ホットフィックスブランチからリリースを直接ビルドおよびデプロイする必要がありますか？
• 既にマージされたリリースから除外されるべき機能に対処する賢明な方法はありますか？これらの場合、独立した開発ブランチは本当に利点ですか？とにかく、ほとんどの場合、手動でコミットを元に戻して元に戻すことになります。

私が直面している問題は、あなたが始めた貧弱な分岐戦略の副作用に過ぎません：現在の本番コードを介して、新しい開発develop（つまり、将来の本番コードに収束するもの）を効果的に耕しています。通常、将来のコードは現在のものとは異なるため、これは要件と問題の矛盾につながります。master

• 合併後に見られる回帰-新しい開発は、生産不安定化developへのmaster
• 生産を安定させると、将来の開発が遅くなります-安定developさせる必要があります。master

ドロップしてdevelopも（ほとんど）助けにはなりません。問題を解消するのではなく、問題のdevelop特定の部分をに転送するだけですmaster。

より良いアプローチは、現在の/将来の開発の背後に本番を移動し、What is Your Branching Model？：

トランクで何が起こっているかではなく、上の画像ではリリースブランチのみを参照していることに注意してください。

これはあなたにとってどのように機能しますか：

• developあなたが望むように、枝は消え去りますmaster
• masterブランチは、開発が無いスピード制限（それはだと起こる場所です、あなたのトランクで決して生産にマージされません）。
• プロダクションは、プロダクション品質に十分近いと考えられるラベル/タグreleaseから引き出された1つ以上のブランチmasterです（必要に応じて、そのブランチで残りのToDoアイテムの短いリストに対処できます）。これらの枝だけからダイレクトホット・フィックスおよび/またはチェリー摘み修正を受けることができmaster、それらはされないと合併していないmasterか、他の支店
• ホットフィックスはreleaseブランチへの直接コミットです

ホットフィックスが実稼働バージョンにのみ適用され、適用されない場合masterは、直接releaseブランチにコミットされます。両方に適用される場合、通常はmaster最初にコミットされ、releaseブランチに対してチェリーピック/ダブルコミットされます。

ここで何が行われるかmaster（現在のreleaseブランチが終了するポイントを過ぎています）を見ると、2つのオプションがあります。

• 今日と同じように機能ブランチを続行します。ただし、機能ブランチはベースでmasterはなくベースになりますdevelop。それらをホットフィックスに変換することは引き続き可能です- release代わりに対応するブランチにリベースする必要がありますmaster
• 継続的インテグレーションに切り替えて、その利点を享受します（将来的にいつでも実行できます）。これには、漸進的な方法が含まれます。

このアプローチが気に入った場合は、現在の場所から次の方法でアクセスできます。

• リリースの命名戦略を確立します。
  • 同じ名前の継続的なリリースブランチを持つことはできません
  • 本番リリースブランチをリベースまたは同期することはできません（実際にはできません）。
• その命名戦略に従って、すぐにreleaseXブランチをプルしmasterます
• コミットが入らdevelopないようにすると、彼らはすぐに直進するでしょうmaster。
• に合流developするmaster
• のmaster代わりにワークスペースをリベースするように開発者に指示しますdevelop。
• masterコミット用にオープン
• develop必要に応じて削除します（または参照用に永続的にロック/読み取り専用のままにします）

マスターブランチを取り出し（後で、必要に応じてチームを混乱させるために、Developerの名前をmasterに変更できます）、開発ブランチまたは修正プログラムブランチのリリースにタグを使用するとします。ブランチを取り出しましたが、違いは構文の変更だけです。変更のために変更します。

ここで、ロックされたマスターブランチを保持したまま実際に開発を始めたとします。何が起こるかは、コードの統合が遅くなり、特にリリース日近くに機能ブランチで分離されて長く生きることです。これにより、毎回マージの難易度が上がり、プロセスが遅くなります。

あなたが定めた制約の範囲内で、そのような変更を行うことによるプラスの効果は見られません。特に最初の制約を緩和する必要があります。

プルリクエストブランチとホットフィックスブランチのそれぞれでコードを既にビルドおよびテストしています。つまり、プルリクエストで保留中のすべてのブランチの合計が仮想developブランチになります。

テスト環境で、いくつかのプルリクエストがメインリポジトリに公開されていない一時的なブランチに選択されたときにシステムを作成できます。このブランチはmaster、いくつかの追加プルリクエストを含むテスト環境を統合するために使用されますが、テストが完了すると、このブランチはどこからでも利用できなくなります。

からリリースを作成する場合master、通常はそのリリースにタグを作成します。後の修正プログラムは、そのタグを使用して、展開が行われる新しい修正プログラムブランチを作成できますmaster。このホットフィックスブランチでは、おそらくマイナーリリースにもタグを付け、変更がにマージされていることを確認しmasterます。

マージされた機能をリリースから削除することは、gitでは非常に困難です。これに最適なメカニズムはgit revert、マージコミットで使用することです。しかし、それはこれらの機能/変更を取り戻すことをほぼ不可能にし、歴史はすべて混乱します。

コードの展開と機能のリリースの分離を処理するはるかに良い方法は、機能フラグです。開発者がコード自体の一部の条件の背後に機能を隠すことができる場合、コードをデプロイできますが、機能をオフにすることができます。これは別のトピックですが、これに関する多くの情報があります（devops.SEに関するQ＆Aを含む）。

よく@ dan-cornilescuはあなたの特定の問題に対してそれをうまく言っていますが、トランクベースの開発（Continuous Delivery、Lean Enterprise、およびThe DevOps Handbookで言及されている）のより一般的なケースはここで作成されます：https : //trunkbaseddevelopment.com/