現在では、ほぼすべてのバージョン管理システムがブランチをサポートしています。ブランチとは、1 つの中心的コード ベースから枝分かれした、独立した作業ラインです。
ブランチ戦略は、バージョン管理システムを使用してコードを整理、作成、マージ、デプロイする際に開発者を支援するガイドラインで構成されます。メイン ブランチは、メインライン、デフォルト、またはトランクとも呼ばれ、開発者が独自のブランチを作成し、それと並行して独立して作業するための基盤として機能します。利用可能なさまざまな分岐戦略を理解することは、ソフトウェア開発プロジェクトにおけるコラボレーションを最適化し、コード品質を維持するために不可欠です。
ブランチ戦略のメリット
コラボレーション
ブランチを使用すると、開発者チームは 1 つの中央コード ベース内で簡単にコラボレーションできますが、ブランチが孤立して存在する必要はありません。開発者は他の開発者からの変更を簡単にプル ダウンして機能のコレボレーションを行い、プライベート ブランチが 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 サーバーでは自動的に新しいブランチをテストし、最終のマージアップストリームで発生する「サプライズ」を大幅に減らし、メインコードラインを安定した状態に保つ手助けをしています。
