複雑な分岐現実から単一分岐モデルに移行する方法は？

大規模な組織では、ウォーターフォール手法を使用すると、通常、非常に複雑な分岐構造（ブランチスパゲッティ）が発生します。

複雑な分岐現実からトランクベースの開発のような単一分岐モデルへの移行に使用できる分岐戦略は何ですか？

更新：

明確にするために、質問は移行/移行自体に関するものであり、前後の方法論に関するものではなく、かなり明確です。

「今日のEOBでは、まだ数十億のブランチがある滝ですが、明日はトランクベースの単一ブランチCIに切り替えます」とは言えません。

あなたはウォーターフォールについて言及しているので、あなたがほのめかしている多数のブランチはメンテナンスブランチではなく機能ブランチであることを理解しています。

このセットアップでは、これらのブランチは、競合を最小限に抑えるためのウォーターフォール計画に従って作成されることも想定しています。これは、開発の目標がいくつかの異なる製品を生産することであることを意味します。単一ブランチ開発モデルを使用する場合、単一の製品でも作業することが重要です。複数の製品が単一ブランチ開発モデルで同時に開発される場合、これらの製品のバージョンを効果的に「接着」します。そのため、リポジトリのバージョンaには健全な製品Xとバグのある製品Yがありますが、バージョンb製品Xにはリグレッションがあり、Yにはバグ修正がありますが、XとYは健康です。このような状況では、XとYを別個のリポジトリで開発されていると見なすことを余儀なくされます。

したがって、最初の手順ではリポジトリ分割を実行する必要があります。

1. リポジトリをいくつかの小さなリポジトリに簡単に分割できるように配置します。たとえば、現在のリポジトリを再配置して、各最上位ディレクトリが将来作成するリポジトリに対応するようにします。そうすることで、誰もが精通しているブランチスパゲッティ規律を使い続けることができます。

2. ステップ1が完了したら、1 つのブランチが1つの最上位ディレクトリ内のファイルにしかアクセスできないようにすることで、ブランチスパゲッティの規律を調整します。

3. 各ブランチがステップ2に準拠している場合、分割を実行します。開発者は、パスの最初のレベルを削除するだけで、保留中の変更を簡単に変換して単一のリポジトリにパッチを適用できます。

分割が実行されたので、ブランチディシプリン自体の作業を開始できます。

4. 短命ブランチの開発を支援するプログラミング手法を紹介します。ブランチが短命であることは、すべてのシングルブランチ手法の重要な側面です。彼らの目標の1つは、長命ブランチのマージとデバッグに費やす時間を削減することです。一般的な手法は、「工場」が構成フラグを使用してオブジェクトの履歴バージョンまたはそのオブジェクトの最初に部分的に開発された新しいバージョンを生成する「機能フラグ」の導入です。

5. 今では、それぞれに少数のブランチを備えた無数のリポジトリがあり、トランクで元のブランチスパゲッティマウンテンが崩壊するのを見ることなく、「トランクベースの開発規律をグローバルに採用する」ボタンをオンにできます。

リポジトリの実際の分割はオプションかもしれませんが、その後、提出された各パッチの許可された範囲を明確に描写するポリシーを採用する必要があります（メインブランチの変更をマージする際の競合のリスクを制限するため）。競合にバインドされたオーバーヘッドを削減することは、単一ブランチモデルの方法論の目標の1つであるため、これはあなたのコンテキストに関連すると思います。

何かから何かに移行する場合、定義する必要があるのは次の2つだけです。

1. あなたの目標は何ですか
2. アクセス方法（移行計画）

最初の部分は、悲しいことに、しばしば見落とさかで道あまりにも漠然としました。あなたが持っているものは混乱であり、それを整理したいと単純に言うことはできません。それはどういう意味ですか？誰もが（：すべてのDEVがいることを考えて別名異なる解釈を持っているでしょう、彼または彼女の物事のやり方がベストです）。

可能性は、あなたが持っているすべてのブランチがサービスを提供している、または目的を提供していることです。明確に定義されたターゲットプロセスがなければ、人々は自分に最適な方法で（そして当然のように）自分に合った方法を実行し続けます。

たとえば、Vincent Driessenが「成功したGit分岐モデル」を定義したように、ターゲットを明確に定義する必要があります。このモデルを見ると、非常に正確です。安定したコードがどこにあり、不安定な機能がどこに開発されるべきかを示しています。また、どのように-いつ-分岐、更新、マージバックするかについても説明しています。各ブランチの目的と、それらをどうするかを知っています。Vincentによって提案されたもののバリエーションを使用します。バリエーションはwikiで定義されています。

重要なポイントは、すべてのチームにターゲットを理解させ、同意してもらうことです。自分のお気に入りの分岐モデルを探しているのではなく、すべてのチームメンバーが同意して簡単に使用できるモデルを探していることを人々に思い出させることは価値があるかもしれません。

ターゲットを設定したら、移行計画を詳しく説明できます。その計画は、好きなだけ長くても短くてもかまいません。このような分岐モデルが一晩で課せられるのを見てきました。他の場所では、2〜3回のスプリントで行われました。私たちが改善している限り、それは私にとって重要ではありません。

「最大」またはより重要なブランチから始めることができます。例：「これからは、マスターは常にprodにデプロイされる状態になければならず、devブランチは常にコンパイルする必要があります」（またはルールに関係なく）。次に、バージョン（リリース）ブランチを実施します。その後、機能ブランチを実施します。その後、バージョンブランチでコードのフリーズを強制します（意味がある場合）。

DevOpsは、コミュニケーション、オープン性、効率性がすべてです。これらの概念を念頭に置いて、プロセス全体で伝達する必要があります。

開発チーム以外の人をオブザーバーとしてプロセス会議に招待することをお勧めします。運用担当者または中間管理職は、モデルについて1つまたは2つのことを言う場合があります。開発者のニーズに優先順位を付ける必要がありますが、ブランチモデルを管理方法に合わせることが不可能な場合は、1か月か2か月ではなく、今すぐに理解する必要があります。

本当に大きなチームがある場合は、それでも全員を含めるようにしてください。非常に大きなチームでは、とにかく2、3回の会議になります。そのため、部屋にチームリーダーを招待しますが、ウェブキャストを利用可能にして、全員に知らせてください。提案や懸念がある場合は、チームリーダーに発言することができ、有効であれば、2回目または3回目の会議で対処されます。

実際には、複数分岐のヒドラリポジトリを単一の分岐モデルに変換するのは非常に簡単です。

最初に、それ自体とマスターまたはトランクとの差が最も少ないブランチから始めます。年齢と関連性を調べます。それでも関連がある場合は、それらを結合して競合を解決します。関連性がなくなった場合は削除します。

すべてのブランチをマージし、すべての競合を解決し、残りのブランチが1つになるまで、このプロセスを続けます。

次の簡単な概要に従って始めることができます。

1. マスター/トランクブランチのコピーを作成して呼び出します temp_master
2. マスター/トランクからの分岐が最も大きいブランチを見つけます。
3. ブランチを保持、アーカイブ、または削除する必要があるかどうかを判断します。
   1. 保持する必要がある場合は、手順4に進みます。
   2. 削除またはアーカイブする必要がある場合は、削除してアーカイブし、手順2に戻ります。
4. ステップ2を繰り返して、次の分岐が最も少ない分岐を見つけます。
5. ステップ2とステップ3で見つかった2つのブランチをマージして、すべての競合を解決します。
6. これらの2つのブランチをブランチにマージしますtemp_master。
7. temp_masterコードでコードをテストして、コンパイルおよびビルドされるかどうかを確認し、健全性のために他の自動テストを実行します。
   1. テストが失敗した場合は、戻って理由を見つけて修正し、プロセスを繰り返します。
   2. それでもテストが失敗する場合は、作業する2つの異なるブランチを選択します。
8. マスター/トランクとのブランチが2つだけになるまで、手順2〜7を繰り返しますtemp_master。
9. 最後に、temp_masterマスター/トランクにマージし、新しいシングルブランチモデルでライブします。

典型的な4週間のスプリントサイクルを持つ大規模な組織のためのGit-Flowは masterブランチが2に従うことによって、不要なコミットから清潔に保たれますが、機能ブランチのマスター生産準備支店の利益はまた、常に展開可能である得るための好ましいアプローチである、機能からに（サイクルをコミットDevelopし、Developブランチマスターへ）。

さらに、分岐は製品リリースの頻度によっても決まります。本番環境に頻繁に展開するには、機能ブランチまたは集中型モデルを使用することをお勧めします。この場合、ブランチ管理のオーバーヘッドは、生産の安定性を維持するために、より低い環境での堅牢なテストにシフトされます。