ブランチ戦略とは

ブランチングを行えば、開発者チームはひとつの中心的コード ベースの内部で容易に共同作業ができます。開発者がブランチを作成すると、バージョン管理システムはその時点でのコード ベースのコピーを作成します。ブランチに変更を加えても、チームの他の開発者には影響を与えません。これは大変好都合です。もしすべての作業が main コード ラインで行われているとしたら、開発中のフューチャーは不安定であるため、極めて危険性が高いからです。かといって、ブランチを隔離する必要はありません。開発者はフィーチャーで共同作業を行う他の開発者から簡単に変更を切り離して、main から少し離れた状態で自分たちのブランチを分化させておくことができます。

ブランチング モデルは往々にしてチーム間で異なるため、ソフトウェア コミュニティで議論のテーマとなります。大きなテーマのひとつは、main にマ―ジして戻すにあたり、どの程度の作業をブランチに残するべきか、ということです。

リリース ブランチング

リリース ブランチングとは、1 回のリリースは完全に 1 つのブランチに含まれるという概念です。つまり、開発サイクルの後半になると、リリース マネージャーは main からブランチ (例: 「1.1 開発ブランチ」) を作成します。1.1 リリースへの変更すべてを 2 回適用する必要があります。一度は 1.1 ブランチ、さらにもう一度、main のコード ラインに適用します。2 つのブランチでの作業はチームにとって負担であるとともに、2 つのブランチのマージを忘れる可能性も高くなります。多くのメンバーが同じブランチで作業をしていると、リリース ブランチの管理は大掛かりで大変です。単一のブランチに多くのさまざまな変更をマージする際の苦労は誰もが経験しています。リリース ブランチが必要な場合は、実際のリリースにできるだけ近い状態のブランチを作成します。

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

フィーチャー ブランチはよく、製品の機能を有効/無効にする「トグル」となる機能フラグと併用されます。これによって、機能をアクティブにする際に main にコードをデプロイして、管理することが容易になるとともに、機能をエンド ユーザー向けに公開する前にコードを最初にデプロイすることも容易になります。

タスクブランチング

Atlassian では、タスク単位のブランチによるワークフローが中心となっています。Jira などの課題追跡アプリケーションで、各組織が作業をタスクごとに自然に振り分けることができます。すると、チームにとって課題が作業に対する接点の中心となります。課題ブランチングともいわれるタスク ブランチングは、ソース コードから課題に直接繋がっていきます。課題はそれぞれ、ブランチ名に含まれる課題キーとともにその課題のブランチで実施されます。課題キーをブランチ名から探せばよいので、どのコードがどの課題を実施しているのかわかりやくなります。このような透明性から、main や古いリリース ブランチに特化した変更の適用がより簡単になります。

アジャイルはユーザー ストーリーを軸として展開しているため、タスク ブランチはアジャイル開発との相性が良いのも特徴です。各ユーザー ストーリー (またはバグ修正) はそれぞれのブランチ内にあり、進行中の課題や、リリース準備の整った課題を把握しやすくなっています。

わたしたちは皆、複数のブランチを一つの実用的なソリューションに統合するために苦労しています。今までは、Subversion などの集中型バージョン管理システムで大変なマージ作業を行っていました。ですが、Git や Mercurial などの最近のバージョン管理システムでは、異なるブランチにおけるライブ状態のバージョンファイルをトラッキングできる、異なる方法を採用しています。

マージがより簡単になり、コードベース全体でより柔軟になるにつれ、ブランチの使用期間は短くなってきています。CI（継続的インテグレーション）の一環として頻繁かつ自動的にブランチをマージする機能と、使用期間の短いブランチではより小さな変更しかなされていないという事実。Git や Mercurial を活用しているチームにとって、この狭間の「地獄のようなマージ」はもう過去のものです。

これでタスク ブランチングが素晴らしいものに!

バージョン管理システムは、マージの結果にまでしか影響を与えません。自動化されたテストと継続的インテグレーションはともに大変重要です。ほとんどの CI サーバーでは自動的に新しいブランチをテストし、最終のマージアップストリームで発生する「サプライズ」を大幅に減らし、メインコードラインを安定した状態に保つ手助けをしています。