ソースコードブランチ管理のパターン

ソースブランチ

コピーを作成し、そのコピーへのすべての変更を記録します。

複数の人が同じコードベースで作業すると、同じファイルで作業することがすぐに不可能になります。コンパイルを実行したい場合に、同僚が式を入力している最中だと、コンパイルは失敗します。「コンパイル中だから、何も変更しないで」と互いに叫ぶ必要があります。2人でもこれは維持するのが難しく、チームが大きくなると理解不能になります。

これに対する簡単な解決策は、各開発者がコードベースのコピーを作成することです。これで、自分の機能を簡単に作業できますが、新しい問題が発生します。作業が完了したら、2つのコピーをどのようにマージしますか？

ソースコード管理システムは、このプロセスをはるかに容易にします。重要なのは、各ブランチに加えられたすべての変更をコミットとして記録することです。これにより、`utils.java`に加えた小さな変更を誰も忘れないだけでなく、変更を記録することで、特に複数の人が同じファイルを変更した場合に、マージが容易になります。

これにより、この記事で使用しているブランチの定義につながります。私は**ブランチ**を、コードベースへのコミットの特定のシーケンスとして定義します。ブランチの**ヘッド**または**先端**は、そのシーケンスの最新のコミットです。

名詞ですが、動詞「ブランチする」もあります。これによって、新しいブランチを作成することを意味しますが、元のブランチを2つに分割することと考えることもできます。ブランチは、1つのブランチからのコミットが別のブランチに適用されるとマージされます。

私が「ブランチ」に使用している定義は、私がほとんどの開発者がそれらについて話しているのを観察した方法に対応しています。しかし、ソースコード管理システムは、「ブランチ」をより具体的な方法で使用することがあります。

これは、共有gitリポジトリにソースコードを保持している最新の開発チームにおける一般的な状況で説明できます。開発者の1人であるスカーレットは、いくつかの変更を加える必要があるため、そのgitリポジトリをクローンしてmasterブランチをチェックアウトします。彼女はいくつかの変更を加え、masterに戻ってコミットします。一方、別の開発者（バイオレットと呼びましょう）は、リポジトリを自分のデスクトップにクローンしてmasterブランチをチェックアウトします。スカーレットとバイオレットは同じブランチで作業していますか、それとも異なるブランチで作業していますか？どちらも「master」で作業していますが、それらのコミットは互いに独立しており、共有リポジトリにそれらの変更をプッシュするときにマージする必要があります。スカーレットが自分の行った変更について確信が持てないことにした場合、彼女は最後のコミットにタグを付け、masterブランチをorigin/master（共有リポジトリからクローンした最後のコミット）にリセットします。

私が前に説明したブランチの定義によると、スカーレットとバイオレットは別々のブランチで作業しており、互いに別々であり、共有リポジトリのmasterブランチからも別々です。スカーレットがタグで作業を脇に置くと、私の定義によると（そして彼女はブランチと考えている可能性があります）それでもブランチですが、gitの言い回しでは、タグ付けされたコードラインです。

gitのような分散型バージョン管理システムでは、リポジトリをさらにクローンするたびに、追加のブランチも得られます。スカーレットが自宅への電車で使用するラップトップにローカルリポジトリをクローンすると、3つ目のmasterブランチが作成されます。GitHubでのフォークでも同じ効果が発生します。フォークされた各リポジトリには、独自の追加のブランチセットがあります。

この用語の混乱は、さまざまなバージョン管理システムを使用すると悪化します。それらすべてには、ブランチを構成するものに関する独自の定義があるためです。Mercurialのブランチはgitのブランチとはかなり異なり、Mercurialのブックマークにより近いです。Mercurialは名前のないヘッドでブランチを作成することもでき、Mercurialのユーザーはリポジトリをクローンしてブランチを作成することがよくあります。

この用語の混乱すべてにより、一部の人は用語の使用を避けるようになります。ここで役立つより一般的な用語はコードラインです。私は**コードライン**を、コードベースの特定のバージョンのシーケンスとして定義します。それはタグで終わったり、ブランチになったり、gitのreflogで失われたりする可能性があります。私のブランチとコードラインの定義の間に強い類似性があることに気付くでしょう。コードラインは多くの点でより有用な用語であり、私も使用していますが、実際にはそれほど広く使用されていません。そのため、この記事では、git（または他のツールの）用語の特定のコンテキストでない限り、ブランチとコードラインを交換可能に使用します。

この定義の結果として、使用しているバージョン管理システムに関係なく、ローカルの変更を行うとすぐに、各開発者には少なくとも1つの個人コードラインが自分のマシンの作業コピーにあります。プロジェクトのgitリポジトリをクローンし、masterをチェックアウトして、いくつかのファイルを更新すると、何もコミットする前でも新しいコードラインになります。同様に、Subversionリポジトリのトランクの独自の作業コピーを作成した場合、Subversionブランチが関与していなくても、その作業コピーは独自のコードラインです。

メインライン

製品の現在の状態として機能する単一の共有ブランチ

**メインライン**は、チームのコードの現在の状態と見なされる特別なコードラインです。新しい作業を開始したいときはいつでも、作業を開始するためにメインラインからコードをローカルリポジトリにプルします。チームの他のメンバーと作業を共有したいときはいつでも、できれば後ほど説明するメインライン統合パターンを使用して、そのメインラインを自分の作業で更新します。

異なるチームはこの特別なブランチに異なる名前を使用しており、多くの場合、使用されているバージョン管理システムの規則によって推奨されています。gitユーザーはしばしば「master」と呼び、Subversionユーザーは通常「trunk」と呼びます。

ここで強調しなければならないのは、メインラインは*単一の共有*コードラインであるということです。人々がgitで「master」について話すとき、すべてのレポジトリのクローンが独自のローカルmasterを持っているため、いくつかの異なる意味を持つ場合があります。通常、このようなチームには**中央リポジトリ**があります。これは、プロジェクトの単一の情報源として機能し、ほとんどのクローンの起点となる共有リポジトリです。ゼロから新しい作業を開始することは、その中央リポジトリをクローンすることを意味します。すでにクローンがある場合は、中央リポジトリからmasterをプルして、メインラインと最新の状態にします。この場合、メインラインは中央リポジトリのmasterブランチです。

機能に取り組んでいる間は、ローカルmasterである可能性のある独自の個人開発ブランチを持っています。または、個別のローカルブランチを作成することもできます。しばらくの間これに取り組んでいる場合は、定期的にメインラインの変更をプルして個人開発ブランチにマージすることで、メインラインの変更を最新の状態に保つことができます。

同様に、製品の新しいバージョンをリリースしたい場合は、現在のメインラインから始めることができます。製品をリリースするのに十分安定させるためにバグを修正する必要がある場合は、リリースブランチを使用できます。

健全なブランチ

各コミットで、通常はビルドとテストの実行を行い、ブランチに欠陥がないことを確認するための自動化されたチェックを実行します。

メインラインにはこの共有された承認済みの状態があるため、安定した状態に保つことが重要です。2000年代初頭、私は、各製品の毎日のビルドを行うことで有名だった別の組織のチームと話したことを覚えています。これは当時非常に高度な実践と考えられており、この組織はその実践で称賛されました。そのような記事では言及されていなかったのは、これらの毎日のビルドが常に成功したわけではないということです。実際、毎日のビルドが数ヶ月間コンパイルされなかったチームを見つけるのは珍しいことではありませんでした。

これに対抗するために、ブランチを健全に保つよう努めることができます。つまり、正常にビルドされ、ソフトウェアはほとんどバグがないか、まったくバグがない状態で実行されることを意味します。これを確実にするために、私は自己テストコードを書くことが不可欠であることがわかりました。この開発プラクティスは、プロダクションコードを作成するときに、包括的な自動テストスイートも作成することを意味します。これにより、これらのテストに合格した場合、コードにバグが含まれていないことを確信できます。これを行うと、すべてのコミットでビルドを実行することでブランチを健全に保つことができます。このビルドには、このテストスイートの実行が含まれます。システムのコンパイルに失敗した場合、またはテストに失敗した場合、私たちの最優先事項は、そのブランチで他のことを行う前にそれらを修正することです。多くの場合、これはブランチを「凍結する」ことを意味します。健全な状態に戻すための修正を除いて、そのブランチへのコミットは許可されません。

健全性に対する十分な信頼を提供するテストの程度に関して、緊張があります。より徹底的なテストの多くを実行するには多くの時間がかかるため、コミットが健全かどうかについてのフィードバックが遅れます。チームは、デプロイメントパイプラインでテストを複数の段階に分割することによってこれに対処します。これらのテストの最初の段階は迅速に実行する必要があり、通常は10分以内ですが、それでも合理的に包括的である必要があります。私はそのようなスイートを**コミットスイート**と呼びます（コミットスイートは通常主に単体テストであるため、「単体テスト」と呼ばれることがよくあります）。

理想的には、すべてのコミットでテストの全範囲を実行する必要があります。ただし、サーバーを数時間浸す必要があるパフォーマンステストなど、テストが遅い場合は、実際的ではありません。今日では、チームは通常、すべてのコミットで実行できるコミットスイートを構築し、可能な限り頻繁にデプロイメントパイプラインの後の段階を実行できます。

コードがバグなしで実行されるだけでは、コードが良いとは言えません。着実な配信ペースを維持するには、コードの内部品質を高く維持する必要があります。それを行う一般的な方法は統合前レビューを使用することですが、後ほど説明するように、他の代替案もあります。

メインライン統合

開発者は、メインラインからプルし、マージし、健全であればメインラインにプッシュすることで作業を統合します。

メインラインは、チームのソフトウェアの現在の状態を明確に定義します。メインラインを使用することの最大の利点の1つは、統合が簡素化されることです。メインラインがない場合、上記で説明したように、チームの全員と調整するという複雑なタスクになります。しかし、メインラインを使用すると、各開発者は独自に統合できます。

これがどのように機能するかについて、例を説明します。Scarlettと呼ぶ開発者は、メインラインを自分のリポジトリにクローンすることで作業を開始します。gitの場合、中央リポジトリのクローンがまだない場合は、それをクローンしてmasterブランチをチェックアウトします。クローンが既に存在する場合は、メインラインからローカルmasterにプルします。その後、ローカルで作業し、ローカルmasterにコミットできます。

スカーレットが作業している間、同僚のバイオレットがメインラインにいくつかの変更をプッシュします。スカーレットは自身のコードラインで作業しているので、自身のタスクに取り組んでいる間、これらの変更に気付かない可能性があります。

ある時点で、スカーレットは統合したい時点に到達します。最初のステップは、現在のメインラインの状態をローカルのマスターブランチにフェッチすることです。これにより、バイオレットの変更が取り込まれます。ローカルのマスターで作業しているので、コミットはorigin/masterに別のコードラインとして表示されます。

次に、スカーレットは自身の変更とバイオレットの変更を組み合わせる必要があります。いくつかのチームはマージによってこれを行うことを好みますが、他のチームはリベースを使用します。一般的に、人々はブランチをまとめることを話すときは「マージ」という言葉を使用しますが、実際にはgit merge操作やリベース操作を使用しているかどうかは関係ありません。「マージ」と「リベース」の違いについて議論している場合を除き、「マージ」をどちらでも実装できる論理的なタスクとみなします。

標準のマージを使用するかどうか、高速フォワードマージを使用または回避するかどうか、リベースを使用するかどうかについては、別の議論があります。これはこの記事の範囲外ですが、もし十分な量のトリプル・カルメリエを送ってくれる人がいれば、その問題に関する記事を書くかもしれません。結局のところ、quid-pro-quos（見返り）は最近流行っています。

スカーレットが幸運であれば、バイオレットのコードのマージはクリーンなマージになります。そうでない場合は、いくつかの競合を処理する必要があります。これらはテキストの競合である可能性があり、そのほとんどはソース管理システムが自動的に処理できます。しかし、セマンティックな競合ははるかに対処が難しく、ここで自己テストコードが非常に役立ちます。（競合はかなりの量の作業を生み出し、常に多くの作業のリスクを伴うため、黄色い塊で警告します。）

この時点で、スカーレットはマージされたコードがメインラインの健全性基準を満たしていることを確認する必要があります（メインラインが健全なブランチであると仮定します）。これは通常、コードをビルドし、メインラインのコミットスイートを構成するテストを実行することを意味します。クリーンなマージであっても、クリーンなマージでもセマンティックな競合が隠れている可能性があるため、これを行う必要があります。コミットスイートの失敗は、マージにのみ起因する必要があります。なぜなら、両方のマージ親は正常である必要があるからです。これを認識することで、手がかりとなる差分を確認できるため、問題の追跡に役立ちます。

このビルドとテストにより、スカーレットはメインラインを自身のコードラインに正常に取り込みましたが、—そしてこれは重要であり、しばしば見落とされます—まだメインラインとの統合を完了していません。統合を完了するには、変更をメインラインにプッシュする必要があります。これを行わない限り、チームの他の全員がスカーレットの変更から隔離され、本質的に統合されません。統合はプルとプッシュの両方です。スカーレットがプッシュした後にのみ、彼女の作業がプロジェクトの残りの部分と統合されます。

最近の多くのチームは、コミットがメインラインに追加される前にコードレビューステップを要求しています。これは私が統合前レビューと呼ぶパターンであり、後で説明します。

時折、スカーレットがプッシュする前に、他の誰かがメインラインと統合する場合があります。その場合、彼女は再度プルしてマージする必要があります。通常、これは時折の問題に過ぎず、さらなる調整なしで解決できます。ビルド時間が長いチームが統合バトンを使用しているのを見たことがあります。そのため、バトンを持っている開発者だけが統合できます。しかし、ビルド時間が改善された近年では、それほど多くは聞いていません。

フィーチャーブランチング

フィーチャーのすべての作業を独自のブランチに配置し、フィーチャーが完了したらメインラインに統合します。

フィーチャーブランチングでは、開発者はフィーチャーの作業を開始するときにブランチを開き、完了するまでそのフィーチャーで作業を続け、次にメインラインと統合します。

たとえば、スカーレットを追跡しましょう。彼女は、ウェブサイトへの地方税の徴収を追加するというフィーチャーに取り組みます。彼女は製品の現在の安定バージョンから開始し、メインラインをローカルリポジトリにプルしてから、現在のメインラインの先端から始まる新しいブランチを作成します。彼女は必要なだけフィーチャーで作業し、そのローカルブランチに一連のコミットを行います。

他のユーザーが変更を確認できるように、そのブランチをプロジェクトリポジトリにプッシュする場合があります。

作業中に、他のコミットがメインラインに着陸します。そのため、時折メインラインからプルして、そこに変更がある場合に自分のフィーチャーに影響する可能性があるかどうかを確認することができます。

これは上記で説明した統合ではありません。なぜなら、彼女はメインラインにプッシュバックしていないからです。現時点では、彼女だけが自分の作業を見ており、他のユーザーは見ていません。

統合されているかどうかに関係なく、すべてのコードを中央リポジトリに保持することを好むチームもあります。この場合、スカーレットはフィーチャーブランチを中央リポジトリにプッシュします。これにより、他のチームメンバーも彼女の作業内容を確認できます。他の人の作業にまだ統合されていない場合でもです。

フィーチャーの作業が完了したら、メインライン統合を実行して、製品にフィーチャーを取り込みます。

スカーレットが同時に複数のフィーチャーで作業する場合は、それぞれに別のブランチを開きます。

継続的インテグレーション

開発者は、共有できる健全なコミットを作成したらすぐに、通常は1日分の作業量未満で、メインラインへの統合を行います。

チームが高頻度統合がより効率的でストレスが少ないことを経験すると、「どのくらいの頻度でできるか？」という自然な疑問が生じます。機能ブランチは、変更セットのサイズの下限を意味します。まとまりのある機能よりも小さくすることはできません。

継続的インテグレーションは、統合のための異なるトリガーを適用します。機能で一定の進捗があり、ブランチの状態が良好な場合に統合します。機能が完了している必要はなく、コードベースに価値のある変更が加えられていることだけです。経験則としては、"全員が毎日メインラインにコミットする"、より正確には、*ローカルリポジトリに統合されていない作業が1日分以上残るべきではない*ということです。実際には、継続的インテグレーションの実践者のほとんどは、1時間分の作業量以下の作業でも喜んで統合を行うため、1日に何度も統合を行います。

継続的インテグレーションを使用する開発者は、部分的に構築された機能で頻繁な統合ポイントに到達するという考えに慣れる必要があります。稼働中のシステムで部分的に構築された機能を公開せずにこれを行う方法を検討する必要があります。多くの場合、これは簡単です。クーポンコードに依存する割引アルゴリズムを実装していて、そのコードが有効なリストにまだない場合、たとえ本番環境にあっても、コードは呼び出されません。同様に、保険請求者に喫煙者かどうかを尋ねる機能を追加する場合、コードの背後にあるロジックを構築およびテストし、機能の構築の最終日まで質問するUIを残しておくことで、本番環境で使用されないようにすることができます。キーストーンインターフェースを最後に接続することで、部分的に構築された機能を隠すことは、多くの場合効果的な手法です。

部分的な機能を簡単に隠す方法がない場合は、機能フラグを使用できます。部分的に構築された機能を隠すだけでなく、このようなフラグを使用すると、機能をユーザーのサブセットに選択的に公開することもできます。これは、新しい機能を徐々に展開する場合に役立ちます。

部分的に構築された機能の統合は、特にメインラインにバグのあるコードがあることを心配する人を懸念させます。その結果、継続的インテグレーションを使用する人は、自己テストコードも必要です。これにより、部分的に構築された機能をメインラインに含めても、バグが発生する可能性が高まらないという確信を持つことができます。このアプローチでは、開発者は、機能コードを作成するときに部分的に構築された機能のテストを作成し、機能コードとテストの両方を同時にメインラインにコミットします（おそらくテスト駆動開発を使用します）。

ローカルリポジトリに関して言えば、継続的インテグレーションを使用するほとんどの人は、作業を行うために個別のローカルブランチを使用しません。通常は、ローカルマスターにコミットし、完了したらメインライン統合を実行するのは簡単です。ただし、開発者が好む場合は、機能ブランチを開いてそこで作業を行い、頻繁な間隔でローカルマスターとメインラインに統合しても問題ありません。機能ブランチと継続的インテグレーションの違いは、機能ブランチがあるかどうかではなく、開発者がいつメインラインに統合するかです。

統合前レビュー

メインラインへのすべてのコミットは、コミットが承認される前にピアレビューされます。

コードレビューは、コードの品質向上、モジュール化の向上、可読性の向上、欠陥の除去の方法として長く推奨されてきました。それにもかかわらず、商用組織は、ソフトウェア開発ワークフローに適合させることが困難であることがよくありました。しかし、オープンソースの世界では、プロジェクトへの貢献は承認する前にレビューされるべきであるという考えが広く採用され、このアプローチは近年、特にシリコンバレーで開発組織に広く普及しています。このようなワークフローは、GitHubのプルリクエストメカニズムと特に適合します。

このワークフローは、スカーレットが統合したい作業を完了したときに始まります。メインラインにプッシュする前ですが、正常にビルドされた後、メインライン統合を行う（彼女のチームがそれを実践している場合）と、彼女はレビューのためにコミットを送信します。チームの他のメンバー、例えばバイオレットは、そのコミットをコードレビューします。彼女がコミットに問題がある場合、コメントを行い、スカーレットとバイオレットの両方が満足するまでやり取りが行われます。完了してから初めて、コミットがメインラインに配置されます。

統合前レビューはオープンソースで人気が高まり、コミットされたメンテナと時折の貢献者の組織モデルと非常によく適合しています。それらは、メンテナがすべての貢献を綿密に監視できるようにします。また、フィーチャブランチともよく調和します。完了した機能は、このようなコードレビューを行う明確なポイントを示すためです。貢献者が機能を完了するかどうかが確実でない場合、部分的な作業をレビューする理由は何でしょうか？機能が完了するまで待つ方が良いでしょう。このプラクティスは、より大規模なインターネット企業にも広く普及しており、GoogleとFacebookはどちらも、この作業を円滑に進めるための特別なツールを構築しています。

タイムリーな統合前レビューのための規律を開発することが重要です。開発者が作業を完了し、数日間他の作業に移行した場合、レビューのコメントが返ってきたとき、その作業はもはや彼らの念頭にありません。これは完了した機能ではイライラしますが、レビューが確認されるまでさらに進めるのが困難な可能性がある、部分的に完了した機能ではさらに悪化します。原則として、統合前レビューで継続的インテグレーションを行うことは可能であり、実際には可能です。Googleはこのアプローチに従っています。しかし、これは可能ですが、困難であり、比較的まれです。統合前レビューとフィーチャブランチは、より一般的な組み合わせです。

リリースブランチ

リリースの準備ができた製品のバージョンを安定させるために承認されたコミットのみを受け入れるブランチ。

一般的なリリースブランチは現在のメインラインからコピーされますが、新しい機能を追加することは許可されません。メイン開発チームは引き続きメインラインにそのような機能を追加し、これらは将来のリリースで採用されます。リリースに取り組んでいる開発者は、リリースが本番環境で使用できる状態になるのを妨げる欠陥を排除することにのみ重点を置いています。これらの欠陥に対する修正は、リリースブランチで作成され、メインラインにマージされます。対処すべき欠陥がなくなると、ブランチは本番リリースの準備が整います。

リリースブランチでの修正の作業範囲は（うまくいけば）新しい機能コードよりも小さいですが、時間が経つにつれてメインラインにマージすることがますます困難になります。ブランチは必然的に分岐するため、より多くのコミットがメインラインを変更するにつれて、リリースブランチをメインラインにマージすることが困難になります。

この方法でコミットをリリースブランチに適用することの問題点は、特に分岐によって困難になるにつれて、メインラインにコピーすることを怠りやすいことです。その結果生じる回帰は非常に恥ずかしいものです。そのため、一部の人はメインラインでコミットを作成することを好み、動作するようになったら、それらをリリースブランチにチェリーピックします。

**チェリーピック**とは、コミットが1つのブランチから別のブランチにコピーされますが、ブランチはマージされません。つまり、ブランチポイント以降の前のコミットではなく、1つのコミットのみがコピーされます。この例では、F1をリリースブランチにマージした場合、M4とM5が含まれます。しかし、チェリーピックはF1のみを取得します。チェリーピックはM4とM5で行われた変更に依存する可能性があるため、リリースブランチにはきれいに適用されない可能性があります。

メインラインにリリース修正を書き込むことの欠点は、多くのチームがそれを実行するのが難しく、メインラインで一方的に修正し、リリース前にリリースブランチで修正し直さなければならないことに不満を抱くことです。これは、リリースを迅速に出荷する必要がある場合、特に当てはまります。

一度に本番環境で1つのバージョンしか運用していないチームは、単一のリリースブランチだけで済みますが、一部の製品では、本番環境で使用されているリリースが多数存在します。顧客のキット上で実行されるソフトウェアは、顧客が希望する場合にのみアップグレードされます。多くの顧客は、アップグレードの失敗によって痛い目に遭っているため、魅力的な新機能がない限り、アップグレードを嫌がります。しかし、そのような顧客も、特にセキュリティの問題に関連するバグ修正を必要としています。このような状況では、開発チームは、使用されている各リリースに対してリリースブランチを開いたままにし、必要に応じて修正を適用します。

開発が進むにつれて、古いリリースに修正を適用することがますます困難になりますが、それは多くの場合、ビジネスのコストです。これは、顧客に最新のバージョンに頻繁にアップグレードすることを促すことによってのみ軽減できます。製品の安定性を維持することはこれにとって不可欠です。一度痛い目に遭った顧客は、二度と不要なアップグレードを行うことをためらいます。

（リリースブランチの他の名称として、「リリース準備ブランチ」、「安定化ブランチ」、「候補ブランチ」、「強化ブランチ」などを聞いたことがあります。「リリースブランチ」が最も一般的なようです。）

成熟度ブランチ

そのヘッドがコードベースの成熟度のレベルの最新バージョンを示すブランチ。

チームは、ソースの最新バージョンを知りたいことがよくあります。これは、成熟度のレベルが異なるコードベースでは複雑になる可能性があります。QAエンジニアは製品の最新のステージングバージョンを確認したい場合があり、本番環境の障害をデバッグしている人は最新のバージョンを確認したい場合があります。

成熟度ブランチは、この追跡を行う方法を提供します。コードベースのあるバージョンが特定のレベルの準備状態に達すると、特定のブランチにコピーされるという考え方です。

本番環境用の成熟度ブランチを考えてみましょう。本番リリースの準備ができたら、製品を安定化するためにリリースブランチを開きます。準備ができたら、それを長期間実行される本番ブランチにコピーします。これはマージではなくコピーとして考えています。本番コードは、上流ブランチでテストされたものとまったく同じである必要があるためです。

成熟度ブランチの魅力の1つは、リリースワークフローのその段階に達したコードの各バージョンを明確に示すことです。したがって、上記の例では、本番ブランチには、コミットM1〜3とF1〜2を組み合わせた単一のコミットのみが必要です。これを実行するためのSCMのちょっとした細工がありますが、いずれの場合も、メインラインのきめ細かいコミットへのリンクが失われます。これらのコミットは、後で人々がそれらを追跡するのを助けるために、コミットメッセージに記録する必要があります。

成熟度ブランチは、通常、開発フローの適切な段階にちなんで名付けられています。したがって、「本番ブランチ」、「ステージングブランチ」、「QAブランチ」などの用語があります。時々、本番成熟度ブランチを「リリースブランチ」と呼ぶ人もいます。

バリエーション：長期的なリリースブランチ

これはリリースブランチパターンのバリエーションとして考えることができます。これは、リリース候補の成熟度ブランチと組み合わされています。リリースを行うには、メインラインをこのリリースブランチにコピーします。リリースごとのブランチと同様に、安定性を向上させるためにのみ、リリースブランチにコミットが行われます。これらの修正もメインラインにマージされます。リリースが行われたときにタグを付け、別のリリースを行う必要があるときにメインラインを再度コピーできます。

コミットは、成熟度ブランチで一般的であるようにそのままコピーすることも、マージすることもできます。マージする場合は、リリースブランチのヘッドがメインラインのヘッドと正確に一致するように注意する必要があります。これを行う1つの方法は、マージする前にメインラインに適用されたすべての修正を元に戻すことです。各コミットが完全なリリース候補を表すように、マージ後にコミットを圧縮するチームもあります。（これを難しいと感じる人には、リリースごとに新しいブランチを作成することを好む正当な理由があります。）

このアプローチは、一度に本番環境で1つのリリースのみを実行する製品にのみ適しています。

チームがこのアプローチを好む理由の1つは、リリースブランチのヘッドが常に次のリリース候補を指すことを保証することです。最新のリリースブランチのヘッドを探し出す必要はありません。ただし、少なくともgitでは、チームが新しいリリースブランチを作成するときにハードリセットで移動する「release」ブランチ名を持つことで同じ効果を実現し、古いリリースブランチにタグを残します。

環境ブランチ

ソースコードコミットを適用して、新しい環境で製品を実行するように構成します。

ソフトウェアは、通常、開発者のワークステーション、本番サーバー、およびさまざまなテストとステージング環境など、異なる環境で実行する必要があります。通常、これらの異なる環境で実行するには、データベースにアクセスするために使用されるURL、メッセージングシステムの場所、および主要なリソースのURLなど、いくつかの構成変更が必要です。

環境ブランチとは、製品を異なる環境で実行するように再構成するためにソースコードに適用されるコミットを含むブランチです。メインラインでバージョン2.4を実行しており、ステージングサーバーで実行したいとします。これを行うには、バージョン2.4から始まる新しいブランチを作成し、適切な環境変更を適用し、製品を再構築してステージング環境にデプロイします。

変更は通常手動で適用されますが、担当者がgitに精通している場合は、以前のブランチから変更をチェリーピックすることもできます。

環境ブランチパターンは、多くの場合、成熟度ブランチと組み合わされます。長期間実行されるQA成熟度ブランチには、QA環境の構成調整が含まれている場合があります。このブランチへのマージは、構成変更を取得します。同様に、長期間実行されるリリースブランチには、これらの構成変更が含まれている場合があります。

ホットフィックスブランチ

緊急の製品の欠陥を修正するための作業を記録するブランチ。

本番環境に重大なバグが発生した場合、できるだけ早く修正する必要があります。このバグに対する作業は、チームが行っている他の作業よりも優先順位が高く、他の作業はこのホットフィックスの作業を遅らせるようなことはあってはなりません。

ホットフィックスの作業はソース管理で行う必要があるため、チームはそれを適切に記録し、共同作業を行うことができます。これを行うには、最新のリリースバージョンでブランチを作成し、そのブランチにホットフィックスの変更を適用します。

修正が本番環境に適用され、全員が十分な睡眠時間を確保した後、次のバージョンで回帰がないことを確認するために、ホットフィックスをメインラインに適用できます。次のバージョン用にリリースブランチが開いている場合は、ホットフィックスもそこに適用する必要があります。リリース間の時間が長い場合、ホットフィックスは変更されたコードの上に作成される可能性が高いため、マージがより困難になります。この場合、バグを明らかにする優れたテストが非常に役立ちます。

チームがリリースブランチを使用している場合、ホットフィックスの作業はリリースブランチで行うことができ、完了時に新しいリリースを作成できます。基本的に、これは古いリリースブランチをホットフィックスブランチに変えます。

リリースブランチと同様に、メインラインでホットフィックスを作成し、それをリリースブランチにチェリーピックすることもできます。しかし、ホットフィックスは通常、強い時間的制約の下で行われるため、これはあまり一般的ではありません。

チームが継続的デリバリーを使用している場合、メインラインから直接ホットフィックスをリリースできます。ホットフィックスブランチを使用することもありますが、最後のリリースコミットではなく、最新のコミットから開始します。

新しいリリースを2.2.1とラベル付けしました。チームがこの方法で作業している場合、M4とM5は新しい機能を公開していない可能性が高いためです。もし新しい機能を公開している場合、ホットフィックスは2.3リリースに統合される可能性が高いです。これはもちろん、継続的デリバリーでは、ホットフィックスは通常のリリースプロセスを回避する必要がないことを示しています。チームのリリースプロセスが十分に迅速であれば、ホットフィックスは通常の処理と同じように処理できます。これは継続的デリバリーの考え方における大きな利点です。

継続的デリバリーチームに適した特別な処理の1つは、ホットフィックスが完了するまでメインラインへのコミットを許可しないことです。これは、「誰もがメインラインを修正することよりも重要なタスクを持っていない」という信念に合致しており、実際には、本番環境にまだ送信されていないものも含め、メインラインで見つかったすべての欠陥に当てはまります。（なので、それほど特別な処理ではないのかもしれません。）

リリース列車

定期的な時間間隔でリリースする。列車が定期的に出発するスケジュールのように。開発者は、機能を完了したときにどの列車に乗るかを選択します。

リリース列車を使用するチームは、2週間ごとまたは6か月ごとなど、定期的なリリースサイクルを設定します。列車のスケジュールという比喩に従って、チームが各リリースのリリースブランチをカットする日が設定されます。担当者は、どの列車に乗せたい機能を決定し、その列車を目標に作業を行い、列車が積み込み中に適切なブランチにコミットします。列車が出発したら、そのブランチはリリースブランチになり、修正のみを受け付けます。

毎月列車を使用するチームは、2月のリリースに基づいて3月のブランチを開始します。そして、月が進むにつれて新しい機能を追加します。特定の日付、おそらく月の第3水曜日に、列車は出発し、そのブランチの機能は凍結されます。彼らは4月の列車のための新しいブランチを開始し、そこに新しい機能を追加します。一方、一部の開発者は3月の列車を安定させ、準備が整ったら本番環境にリリースします。3月の列車に適用された修正は、4月の列車にチェリーピックされます。

リリース列車は通常、フィーチャブランチと共に使用されます。スカーレットが自分の機能がいつ完了するかを察知したら、どの列車に乗るかを決定します。3月のリリースに間に合うと思うなら3月の列車に統合しますが、そうでなければ次の列車を待ち、そこで統合します。

一部のチームは、列車が出発する数日前（ハードフリーズ）にソフトフリーズを使用します。リリース列車がソフトフリーズ状態になったら、開発者は、自分の機能が安定していてリリースの準備ができていると確信していない限り、その列車に作業をプッシュすべきではありません。ソフトフリーズ後に追加されたバグを示す機能は、列車上で修正するのではなく、元に戻されます（列車から外されます）。

最近、「リリース列車」という言葉は、SAFeのアジャイルリリース列車の概念を指していることがよくあります。SAFeのアジャイルリリース列車はチーム組織構造であり、共通のリリース列車スケジュールを共有する大規模なチームオブチームを指します。リリース列車パターンを使用していますが、ここで説明するものとは異なります。

バリエーション：将来の列車の積み込み

フィーチャートレインの基本的な例では、新しい列車がプラットフォームに到着し、前の列車が出発するのと同時に機能を積み込みます。しかし、別の方法として、同時に複数の列車が機能を受け入れる方法があります。スカーレットが自分の機能が3月の列車に間に合わないと思う場合でも、ほとんど完成した機能を4月の列車にプッシュし、出発する前にさらにコミットをプッシュして完成させることができます。

定期的に、3月の列車から4月の列車にプルします。一部のチームは、3月の列車が出発したときのみこれを行うことを好むため、マージは1回だけですが、小さなマージの方がはるかに簡単であることを知っている私たちは、できる限り早くすべての3月のコミットをプルすることを好みます。

将来の列車に積み込むことで、4月の機能に取り組んでいる開発者は、3月の列車の作業を邪魔することなく共同作業を行うことができます。ただし、4月の担当者が3月の作業と競合する変更を加えた場合、3月の担当者はフィードバックを受け取らないため、将来のマージが複雑になるという欠点があります。

メインラインからの通常のリリースと比較

リリース列車の主な利点の1つは、本番環境への定期的なリリースサイクルです。しかし、新しい開発のために複数のブランチを持つことは複雑さを増します。目標が定期的なリリースである場合、メインラインを使用して同じように達成できます。リリーススケジュールを決定し、メインラインの先端にあるものからそのスケジュールでリリースブランチをカットします。

もしリリース可能なメインラインがあれば、リリースブランチは必要ありません。このような定期的なリリースでは、定期リリース直前にメインラインにプッシュしなければ、開発者はほぼ完成した機能を次のリリースまで保留しておくことができます。継続的インテグレーションを用いれば、皆はいつでもキーストーンの配置を遅らせたり、機能フラグをオフにして、機能を次の予定されたリリースまで待つことができます。

リリース可能なメインライン

メインラインを十分に健全な状態に保ち、メインラインの先頭を常に本番環境に直接配置できるようにする

このセクションを始めたとき、メインラインを健全なブランチにし、ヘルスチェックを十分に厳しくすれば、いつでもメインラインから直接リリースし、タグでリリースを記録できる、とコメントしました。

この単純なメカニズムの代替となるパターンについて長々と説明してきましたので、チームがこれを実行できるならば、これは優れた選択肢であることを強調したいと思います。

メインラインへのすべてのコミットがリリース可能だからといって、すべてをリリースする必要があるわけではありません。これは継続的デリバリーと継続的デプロイの微妙な違いです。継続的デプロイを使用するチームは、メインラインに承認された変更をすべてリリースしますが、継続的デリバリーでは、すべての変更がリリース可能である一方で、リリースするかどうかはビジネス上の意思決定です。（したがって、継続的デプロイは継続的デリバリーのサブセットです。）継続的デリバリーはいつでもリリースできる選択肢を与えてくれると考えることができ、その選択肢を実行するかどうかは、より広範な問題によって決まります。

実験ブランチ

製品に直接マージされる予定のないコードベースの実験的な作業を集めます。

実験ブランチは、開発者がいくつかのアイデアを試したいが、変更が単純にメインラインに統合されるとは期待していない場合に使用します。すでに使用しているライブラリの優れた代替として考えられる新しいライブラリを発見したかもしれません。切り替えるかどうかを決定するために、ブランチを作成し、関連するシステムの一部をその新しいライブラリを使用して記述したり、書き直したりしてみます。この演習の目的は、コードベースにコードを貢献することではなく、特定のコンテキストで新しいツールの適用可能性について学ぶことです。これは一人で実行することも、同僚と協力して実行することもできます。

同様に、実装する新しい機能があり、それをアプローチするいくつかの方法を見ることができます。どちらの方法を採用するかを決定するために、各代替案に数日費やします。

ここでの重要な点は、実験ブランチのコードは放棄され、メインラインにマージされないという期待があることです。これは絶対的なものではありません。結果が気に入っていて、コードを簡単に統合できる場合は、その機会を無視することはありませんが、そうなることを期待していません。通常の習慣をいくつか緩めるかもしれません。テストを少なくしたり、きれいにリファクタリングしようとするのではなく、無秩序なコードの複製をいくつか行うかもしれません。実験が気に入ったら、実験ブランチをリマインダーとガイドとして使用しますが、コミットは使用せずに、アイデアを本番コードに適用してゼロから作業すると予想しています。

実験ブランチでの作業が完了したら、通常はgitでタグを追加してブランチを削除します。タグは、後で再検討したい場合にコードラインを保持します。その性質を明確にするために、「exp」で始まるタグ名を使用するなどの規則を使用します。

将来ブランチ

他のアプローチでは処理できないほど侵入性の高い変更に使用される単一のブランチ。

これはまれなパターンですが、人々が継続的インテグレーションを使用しているときに時々発生します。チームは、コードベースに非常に侵入性の高い変更を加える必要があり、進行中の作業を統合するための通常のテクニックがうまく適用されない場合があります。この場合、チームはフィーチャブランチによく似たことを行い、将来ブランチを切り出し、メインラインからのみプルし、最後にメインライン統合を行うまで行いません。

将来ブランチとフィーチャブランチの大きな違いは、将来ブランチが1つしかないことです。その結果、将来ブランチで作業する人はメインラインからあまり離れることがなく、対処する必要がある他の分岐ブランチはありません。

将来ブランチで複数の開発者が作業する場合、将来ブランチで継続的インテグレーションを行います。統合を行う際には、変更を統合する前に、まずメインラインから将来ブランチにプルします。これにより統合プロセスは遅くなりますが、将来ブランチを使用するコストです。

共同作業ブランチ

開発者が正式な統合なしにチームの他のメンバーと作業を共有するために作成されたブランチ。

チームがメインラインを使用する場合、ほとんどの共同作業はメインラインを介して行われます。開発者が何をしているかをチームの他のメンバーが認識するのは、メインライン統合が発生した場合のみです。

開発者は統合前に自分の作業を共有したい場合があります。共同作業用のブランチを開くと、アドホックにこれを行うことができます。ブランチはチームの中央リポジトリにプッシュすることも、共同作業者は個人リポジトリから直接プルおよびプッシュすることも、共同作業を処理するための短期的なリポジトリを設定することもできます。

共同作業ブランチは通常一時的なものであり、作業がメインラインに統合されると閉じられます。

チーム統合ブランチ

サブチームがメインラインと統合する前に、互いに統合できるようにする。

大規模なプロジェクトでは、単一の論理コードベースで動作する複数のチームがある場合があります。チーム統合ブランチを使用すると、チームメンバーはメインラインを使用するプロジェクトのすべてのメンバーと統合することなく、互いに統合できます。

効果的に、チームはチーム統合ブランチをチーム内のメインラインとして扱い、全体的なプロジェクトのメインラインと同様に統合します。これらの統合に加えて、チームはプロジェクトのメインラインと統合するための個別の作業を実行します。