知らないと現場で困るバージョン管理システムの基礎知識：DevOps時代の開発者のための構成管理入門（3）（2/3 ページ）

[江口和宏, 山本竜三，株式会社ヌーラボ]

ブランチの2つの落とし穴

　まず、ブランチを分岐してから、そのブランチで長い時間マージを行わないまま作業し続けてしまうと、次第に変更内容が巨大になり、他のブランチとの差異が広がっていきます。

　すると、マージしたときに“競合”を起こしてしまう可能性が高くなるため、マージが非常に面倒で危うい作業になってしまうことがあります。このような事態を避けるには、1つのブランチを長期間マージしないままで作業しないことをお勧めします。

　次に、複数のブランチで同時に作業が進んでいるような場合では、マージの方針を決めておかないと複雑な履歴になってしまいます。

　こうなると、いざというときに後から変更履歴をたどるのが困難になってしまうため、開発メンバー内でマージなどのブランチの運用に関するルールを決めるのが良いと思います。

たどるのが困難なネットワーク図

ブランチの4つの運用モデル

統合ブランチとフィーチャーブランチ

　基本的なブランチの運用としては、「統合ブランチ」「フィーチャーブランチ」の2種類のブランチを使い分ける運用方法が挙げられます。

　新しい機能の追加／バグ修正時には、メインラインとなるブランチから新しいブランチを分岐し、そのブランチ上で開発します。この分岐したブランチは、「1つの機能ないしトピックに関する開発するためのブランチ」という意味で「フィーチャーブランチ」（トピックブランチ）と呼ばれます。

　フィーチャーブランチを分岐したりマージしたりする開発のメインラインとなるブランチは「統合ブランチ」と呼ばれます。統合ブランチはソフトウェアがいつでもリリースできるように、安定した状態を保つことが重要です。

　最低でも統合ブランチに対しては次回以降で紹介する「Jenkins」などのCIツールを利用して自動ビルド・自動テストを行い、問題があった場合に素早く発見・修正できるようにしましょう。

統合ブランチとフィーチャーブランチ

リリースブランチ

　またソフトウェアのリリース時には、「リリースブランチ」というブランチを作成することで、新しい機能の開発とリリース作業を同時に行えます。リリースブランチを作ることで、リリース作業中に並行する新しい機能の開発による変更の影響を受けることはありません。

　リリースブランチでは、ソフトウェアのテスト中にバグが発見された場合など、リリースに必要な修正のみをコミットするようにします。リリースが終了したら統合ブランチに修正を取り込んで開発を続けていきます。

リリースブランチ

A successful Git branching model

　Gitでは、このようなブランチ運用を発展させて体系的にまとめた「A successful Git branching model」と呼ばれるモデルが有名です。このモデルでは、状況に応じてメインブランチ、フィーチャーブランチ、リリースブランチ、ホットフィックスブランチの4種類のブランチを使い分けながら開発を進めていきます。

　この運用方法を補助する「git-flow」というgitの拡張も開発されています。また、GitHubが開発時に利用している「GitHub Flow」というモデルもあります。ぜひ参考にしてみてください。

フィーチャートグル

　さらに別のアプローチとして、そもそもブランチは使用せずにメインラインで全ての開発を行う方法も存在しています。

　この場合、コード中でフラグを利用して設定ファイルなどで機能のオン・オフを切り替えられるようにして開発を進めます。まだリリースしたくない機能をコミットしている場合は、その機能のフラグをオフにしてリリースします。このパターンは「フィーチャートグル」または「フィーチャーフラグ」と呼ばれます。

　このパターンでは、常にメインラインに対してコミットするため、巨大な変更を含んだブランチがあちこちからマージされて競合に悩まされる可能性は低くなります。また、状況やリリースするバージョンに応じて特定の機能をオン／オフする必要性がある場合には、フィーチャーブランチを取り外すより容易に管理できます。

　ただし、フラグ分岐によってコードが複雑になるというデメリットがあります。

ブランチ運用は、臨機応変に

　ソフトウェアの開発には受託開発やWebサービスの開発、パッケージソフトの開発などさまざまな種類が存在しています。さらに、開発組織も数人程度のチームから数十、数百人規模までさまざまです。

　そのため、ブランチの運用に関しては、開発組織や開発するソフトウェアによって適切な運用方法は異なり、絶対的な方法はありません。

　以上で述べたような運用方法などから適した部分を取り込んで試しながら、自分たちの置かれた環境に応じた運用方法を見つけることが重要だと思います。

　次ページでは、ブランチ運用の一例として、筆者が開発メンバーとして所属しているプロジェクト管理ツール「Backlog」でのブランチ運用について紹介します。