現在では、ほぼすべてのバージョン管理システムがブランチをサポートしています。ブランチとは、1 つの中心的コード ベースから枝分かれした、独立した作業ラインです。ご利用のバージョン管理システムによって異なりますが、主要ブランチは main ライン、デフォルト、トランクなどと呼ばれる場合があります。開発者は自身のブランチを main のコード ラインから作成して、main と並行する形で独立した作業を行えます。
ブランチングに悩むことはない
ブランチングを行えば、開発者チームはひとつの中心的コード ベースの内部で容易に共同作業ができます。開発者がブランチを作成すると、バージョン管理システムはその時点でのコード ベースのコピーを作成します。ブランチに変更を加えても、チームの他の開発者には影響を与えません。これは大変好都合です。もしすべての作業が main コード ラインで行われているとしたら、開発中のフューチャーは不安定であるため、極めて危険性が高いからです。かといって、ブランチを隔離する必要はありません。開発者はフィーチャーで共同作業を行う他の開発者から簡単に変更を切り離して、main から少し離れた状態で自分たちのブランチを分化させておくことができます。
ブランチはフィーチャー作業にだけ適しているわけではありません。フレームワークや共有ライブラリの更新など、重要なアーキテクチャ面の変更から影響を受けないように、チームを保護します。
アジャイルチーム向けの 3 つのブランチング戦略
ブランチング モデルは往々にしてチーム間で異なるため、ソフトウェア コミュニティで議論のテーマとなります。大きなテーマのひとつは、main にマ―ジして戻すにあたり、どの程度の作業をブランチに残するべきか、ということです。
リリース ブランチング
リリース・ブランチングとは、1 回のリリース全体が 1 つのブランチに含まれるという概念です。つまり、開発サイクルの終盤になると、リリース・マネージャーは main からブランチ（例：「1.1 開発ブランチ」）を作成します。1.1 リリースへの変更すべてを 2 回適用する必要があります。一度は 1.1 ブランチ、さらにもう一度、main のコード・ラインに適用します。2 つのブランチでの作業はチームにとって負担であるとともに、2 つのブランチのマージを忘れる可能性も高くなります。多くのメンバーが同じブランチで作業をしていると、リリース・ブランチの管理は大掛かりで大変です。単一のブランチに多くのさまざまな変更をマージする際の苦労は誰もが経験しています。リリース・ブランチが必要な場合は、実際のリリースにできるだけ近い状態のブランチを作成します。
市場に出ているソフトウェアのバージョンをサポートするうえで、リリースブランチングは重要です。複数のブランチ (例: 1.1、1.2、2.0 など) で 1 つの製品の開発をサポートしていることがあります。以前のバージョン (例: 1.1) で行った変更は、最近のリリースブランチ (例: 1.2、2.0) にマージする必要があることを常に念頭に置いてください。Git を使用したリリースブランチの管理については、後述のウェビナーをご覧ください。
フィーチャー ブランチング
フィーチャー ブランチはよく、製品のフィーチャーを有効/無効にする「トグル」となるフィーチャー フラグと併用されます。これによって、フィーチャーをアクティブにする際に main にコードをデプロイして、管理することが容易になるとともに、フィーチャーをエンド ユーザー向けに公開する前にコードを最初にデプロイすることも容易になります。
フィーチャーフラグのもうひとつの利点は、コードをビルド内に残しつつ、開発中には非アクティブにできる点です。フィーチャーを有効化した際に、何かに失敗しても、システム管理者は新しいビルドをデプロイする代わりに、フィーチャーフラグを取り消し、良い状態にまで戻すことができます。
タスクブランチング
Atlassian では、タスク単位のブランチによるワークフローが中心となっています。Jira などの課題追跡アプリケーションで、各組織が作業をタスクごとに自然に振り分けることができます。すると、チームにとって課題が作業に対する接点の中心となります。課題ブランチングともいわれるタスク ブランチングは、ソース コードから課題に直接繋がっていきます。課題はそれぞれ、ブランチ名に含まれる課題キーとともにその課題のブランチで実施されます。課題キーをブランチ名から探せばよいので、どのコードがどの課題を実施しているのかわかりやくなります。このような透明性から、main や古いリリース ブランチに特化した変更の適用がより簡単になります。
アジャイルはユーザー ストーリーを軸として展開しているため、タスク ブランチはアジャイル開発との相性が良いのも特徴です。各ユーザー ストーリー (またはバグ修正) はそれぞれのブランチ内にあり、進行中の課題や、リリース準備の整った課題を把握しやすくなっています。
ブランチングの厄介な双子：マージ
わたしたちは皆、複数のブランチを一つの実用的なソリューションに統合するために苦労しています。今までは、Subversion などの集中型バージョン管理システムで大変なマージ作業を行っていました。ですが、Git や Mercurial などの最近のバージョン管理システムでは、異なるブランチにおけるライブ状態のバージョンファイルをトラッキングできる、異なる方法を採用しています。
マージがより簡単になり、コードベース全体でより柔軟になるにつれ、ブランチの使用期間は短くなってきています。CI（継続的インテグレーション）の一環として頻繁かつ自動的にブランチをマージする機能と、使用期間の短いブランチではより小さな変更しかなされていないという事実。Git や Mercurial を活用しているチームにとって、この狭間の「地獄のようなマージ」はもう過去のものです。
これでタスクブランチングが素晴らしいものに!
検証、検証、検証
バージョン管理システムは、マージの結果にまでしか影響を与えません。自動化されたテストと継続的インテグレーションはともに大変重要です。ほとんどの CI サーバーでは自動的に新しいブランチをテストし、最終のマージアップストリームで発生する「サプライズ」を大幅に減らし、メインコードラインを安定した状態に保つ手助けをしています。
