4 ブランチ戦略

ブランチ戦略 (branching strategy)とは、ブランチをどのように切り、どのようにマージし、そして運用に乗せていくかという戦略のことである。Gitで他の人の作業を邪魔せずにファイルに変更を加えていくための機能をブランチ (branch) と呼ぶのであったが、作業を進めていくうちこのブランチをどのように効率的に運用すべきかという疑問が浮かぶ。各々が好き勝手にブランチを切りそしてマージしてしまうと、チーム全体が混乱に陥ることは容易に想像できる。チーム内でブランチの運用を定義しておくことで効率的なプロジェクトの遂行を実現すること、これがブランチ戦略を定める目的である。

以下、代表的なブランチモデルであるGit Flow を紹介する。

4.1 Git Flow

git-flowは、Vincent Driessen が2010年に提案したブランチモデルである (詳細はこちら)。以下の図が git-flow の概観図である。

git-flowでは、役割が決められた以下の5種類のブランチを適宜切り替えながら、開発を進めていく。

4.1.1 メインブランチ (main branch)

Gitリポジトリの作成時に作成されるブランチである。Git Flowではメインブランチに直接コミットすることはない。システム開発で、実際にシステムが稼働している環境を本番環境 (production environment) というが、メインブランチは本番環境でシステムが稼働しているプログラムのみが反映されるブランチである。

4.1.2 開発ブランチ (development branch)

開発ブランチは、本番環境に移行される前のプログラムを保管するためのブランチであり、開発の中心となる。メインブランチと並行しており、削除されることはない。

4.1.3 機能ブランチ (feature branch)

主に、新しい機能を加える作業を行うためのブランチであり、開発ブランチから派生させる。変更を加えるごとに作成されるため、最も頻繁に作成されるブランチである。

4.1.4 リリースブランチ (release branch)

開発したプログラムを本番環境にリリースするために、開発ブランチから派生されるブランチである。リリースに向けた作業が完了したら、メインブランチにマージされる。

4.1.5 Hotfixブランチ (hotfix branch)

発覚したバグを修正するための応急処置用のブランチである。メインブランチから派生され、バグの修正が完了したらメインブランチと開発ブランチの両方にマージされる。

4.2 Git Flow のメリット

Git Flowを採用するメリットとしては、以下が挙げられる。

  • 本番環境にリリースしたプログラム (main branch) と、開発中のプログラム (develop branch) の区別が明確になる
  • リリースした内容の調査は main branch を参照すればよいので簡単になる
  • git-flow用のコマンドでほとんどの管理を行えるので、操作マニュアルを用意しやすい

などが挙げられる。デメリットとしては、上のブランチの概要図を見てもわかるように運用が複雑になる点である。

4.3 研究プロジェクトにおける git-flow の活用？

研究プロジェクトにおけるリリースは、working paperの公開およびその改訂 (査読対応含む) に対応すると思われる。 working paper公開時に

  • 実行可能な分析コード
  • そのコードを走らせて得られた分析結果
  • 原稿

これらをセットで保存しておきたい。git-flow で言えば、

  • 普段の開発は develop branch で行い、
  • working paper が公開できそうになったら relase branch で準備
  • リリースが完了したら main と develop 両方にマージ
  • main にマージされる毎に、タグを付けておく

以上の手順との相性が良いように思われる。こうすることで、プロジェクトの差分が main ブランチに反映され、追跡が容易になる。

「良いように思われる」と書いたのは、こうしたブランチ戦略で研究プロジェクトをまだ遂行したことがないからである。 今後、筆者が取り組む研究プロジェクトで取り入れてみて、本内容を適宜アップデートしたい。