Kosei Kitahara: 2011年11月アーカイブ

今回は分散バージョン管理システムgitと共に用いる「ブランチモデル」について紹介していただきます。gitを使ってみて、その高機能さをどう使えば良いか悩まれた方は、ぜひ本稿をご一読ください。gitそのものの使い方については解説していませんので、その際には『 実用git 』などの書籍を参考にしてください。

git-flow は Vincent Driessen 氏によって書かれた A successful Git branching model (O-Show 氏による日本語訳) というブランチモデルを補助するための git 拡張です。 git-flow を利用する前には、まずこの文章を一読することをおすすめします。 その骨子については、 Voluntas 氏のブログ が参考になります。

git を使うメリットの 1 つは、そのブランチモデルです。しかし gitを使っていると、その高い柔軟性から各開発者ごとにブランチが 分散 しがちであったり、最新バージョンが把握しにくいといった不便を感じることがあります。

このツールを導入することで、git の長所を損なわずに、

• 分散型バージョンコントロールシステムである git に集中型 (Subversion 等) の長所を取り入れることができる
• チーム内でブランチモデルを共通化できる

などの利点を得ることが可能です。

分散型に対する集中型の長所は、

• リポジトリが 1 つのため、管理が簡単
• マスターが 1 つのため、最新バージョンが把握しやすい
• コミットすべきリポジトリがわかりやすい。

と言われています。これは、リポジトリが 1 箇所にあることの長所であり、短所です。 git-flow では、中央と みなす リポジトリ origin を作成することで、この長所を取り入れています。

Git ブランチモデル（ A successful Git branching model より。Creative Commons BY-SA ライセンス）

git-flow のブランチモデルを要約すると、

origin には master, develop という 2 つの メインブランチ を保持します。

• master: リリースブランチ。プロダクトとしてリリースするためのブランチ。リリースしたらタグ付けする。集中型でいう trunk、tag。
• develop: 開発ブランチ。コードが安定し、リリース準備ができたら master へマージする。リリース前はこのブランチが最新バージョンとなる。

各開発者は master, develop の他に、フィーチャーブランチ、リリースブランチ、ホットフィックスブランチという サポートブランチ を利用し分散開発します。このブランチは最終的には破棄されます。各ブランチの目的は

• フィーチャーブランチ: 機能の追加。 develop から分岐し、 develop にマージする。
• リリースブランチ: プロダクトリリースの準備。 機能の追加やマイナーなバグフィックスとは独立させることで、 リリース時に含めるコードを綺麗な状態に保つ（機能追加中で未使用のコードなどを含まないようにする）ことができる。 develop ブランチにリリース予定の機能やバグフィックスがほぼ反映した状態で develop から分岐する。 リリース準備が整ったら, master にマージし、タグをつける。次に develop にマージする。
• ホットフィックスブランチ: リリース後のクリティカルなバグフィックスなど、 現在のプロダクトのバージョンに対する変更用。 master から分岐し、 master にマージし、タグをつける。次に develop にマージする。

となります。このサポートブランチにより、マージ、コミットすべきブランチを明確化することができます。