ブランチトピックブランチと統合ブランチでの運用例

トピックブランチと統合ブランチを使用した運用方法について、簡単な例を使って説明します。

例えば、機能の追加を行うトピックブランチで作業を行なっている途中に、バグの修正を行わなければならなくなったとします。

このような場合でも、統合ブランチは機能追加をはじめる前の状態なので、ここから新たにバグ修正用のトピックブランチをつくることで、機能追加とは独立して作業を始めることが出来ます。

完成したバグ修正の内容は、元の統合ブランチに取り込むことで公開出来ます。

元のブランチに戻って機能追加の作業の続きを行うことが出来ます。

しかし、作業の続きを行うには今のバグ修正、コミットXの内容が必要だったことに気づきました。ここで、コミットXの内容を取り込むには直接mergeする方法と、コミットXを取り込んだ統合ブランチにrebaseする方法があります。

ここでは、統合ブランチにrebaseすることにしました。

これで、コミットXの内容を取り込んだ状態で機能追加の続きをすすめることができます。

このように、ブランチ上手く使うことで異なる作業を並行して進めることができます。

コラム「A successful Git branching model」

Gitでのブランチの運用モデルとして、A successful Git branching modelを紹介します。

この運用モデルでは、大きく分けて

の4種類のブランチを使い分けながら開発を進めていきます。

masterブランチとdevelopブランチの2つをメインブランチとして使用します。

master
masterブランチでは、リリース可能な状態だけを管理します。また、コミットにはタグを使用してリリース番号を記録します。
develop(トピックブランチ)
developブランチでは、先のリリースに向けた普段の開発で使用するブランチです。先に説明した統合ブランチの役割を担います。

フィーチャーブランチでは、先に説明したトピックブランチの役割を担います。

このブランチは新機能の開発や、バグ修正を行う際にdevelopブランチから分岐します。フィーチャーブランチでの作業は基本的に共有する必要がないので、リモートでは管理しません。開発が完了したら、developブランチにマージを行うことで公開します。

リリースブランチでは、リリースの準備を行います。なお慣例として、ブランチ名の頭には release- をつけます。リリースブランチを作ることで、最終的な調整はこのブランチで行いながら、更に次のリリースに向けた開発をdevelopブランチ上ですすめることができます。

普段の開発はdevelopブランチ上で行なっているため、ほとんどリリース可能な状態が近づいてからリリースブランチを作成します。そして、リリースに向けた最終的なバグ修正などの開発を行います。

最終的に、リリースブランチがリリース可能な状態になったらmasterブランチにマージを行い、できたマージコミットに対してリリース番号のタグを追加します。

また、リリースブランチ上で行った修正を取り込むため、developブランチに対してもマージを行います。

リリースした製品に緊急で修正が必要になった場合に、masterブランチから分岐して作成されるブランチです。慣例として、ブランチ名の頭には hotfix- をつけます。

例えば、developブランチ上での開発がまだ中途半端な状態の時に、緊急で修正が必要になったとします。この場合、developブランチからリリース可能なバージョンを作るのは時間がかかるため、masterブランチから直接ブランチを作成して修正を行い、マージします。

修正時に作成したホットフィックスブランチは、developブランチにもマージして取り込みます。