読者です 読者をやめる 読者になる 読者になる

Shoichi Matsuda's diary

このブログは移転しました。 https://shoma2da.net/ が新しいブログです。

アプリ開発にはGitlab flowが合うと思います

チーム GitHub git Android iOS

はじめに

みなさまのプロジェクトではどのようにバージョン管理を行っているでしょうか。
ここでのバージョン管理とは具体的にはどのようなブランチを作ってどこにマージするか、リリースはどのように進めるかといった事柄を指しています。

今日は数あるバージョン管理戦略の中で比較的新しく提唱されたGitlab flowというフローを中心にして話していきたいと思います。
最近アプリの開発においてこのGitlab flowが個人的には一番しっくり来ているのでオススメしたいです。

有名なフロー

gitは分散型のバージョン管理システムとして一世を風靡しており、いまや事実上のデファクトスタンダートです。
名前のとおり分散している(ローカル・リモートが明確に分かれている)ことやブランチ・コミットの編集も非常に容易で柔軟性が非常に高いです。
一方でその柔軟さゆえにルールをきちんと決めなければ各個人のフローが大きく異なって混乱を生んでしまうこともあるでしょう。

こうした問題に対して有名なものとして git flow と GitHub flow といった2つフローが提唱されてきました。
それぞれについて簡単に見ていきます。

git flow

git flowは古参なバージョン管理戦略の一つです。
git-flow cheatsheetでこのフローを実現するためのコマンドも配布されていたりします。

f:id:shoma2da:20151104220344p:plain
A successful Git branching model » nvie.com

git flowでは以下のようなブランチを使用します。

  • master - リリース済みのバージョンをここで管理する。タグ付けもこのブランチで行う。
  • development - 開発の中心となるブランチ。普段のPull Requestのマージ先はここ。
  • hotfixes - リリース内容に問題があった場合に緊急対応を行うためのブランチ。
  • release branch - リリース準備用のブランチ。
  • feature branches - 開発作業を進めるためのブランチ。
メリット

git flowのメリットは管理が他のどのフローよりもしっかりしていることだと思います。
役割ごとに明確に使うタイミングや意図が分けられているためコミットツリーを見ることでどのように作業が進んだかを俯瞰して把握しやすいでしょう。

デメリット

一方で控えめに言ってもgit flowはかなり複雑であると言えるでしょう。
ブランチの種類が多いことやその開始地点やマージ先が多岐にわたっています。
毎回上記の図を見ながら作業できれば良いですが実際にはそうはいきません。
一度目を離すとどれが何を表していたかを思い出すことは至難の技でしょう。

GitHub flow

もう一つの有名な戦略であるGitHub flowを見ていきましょう。
このGitHub flowは他のどのバージョン管理戦略と比較しても最も単純でしょう。

f:id:shoma2da:20151104223339p:plain

端的に言うとmasterブランチとそれ以外、という2パターンの種別でブランチを管理します。
masterから派生したブランチで作業をしてmasterにマージする、ただそれだけです。
(図中のオレンジ色のブランチはrebaseした方が良いといった話もあるかもしれませんが今は細かいところは触れません。)

メリット

特にサーバサイドとの親和性が非常に高いように思います。
CIと絡めて「masterにマージするたびにデプロイ」といった運用も取れるので、うまくすればリリース作業そのものからほぼ解放されそうです。

デメリット

リリースのタイミングを調整したい場合は不向きではないでしょうか。
例えばアプリの場合は1つの作業単位ごとにリリースをするとも限らないのでどのブランチでリリース準備をすれば良いのか迷ってしまいます*1
また、サーバサイドであっても例えば環境(ステージング環境、QA環境、広告配信テスト環境などなど)を分けてデプロイしたい場合はデプロイタイミングとブランチとの結びつきが不明確になってしまうでしょう。

Gitlab flow

それではGitlab flowです。

例1:
f:id:shoma2da:20151104225147p:plain
出典:GitLab Flow | GitLab

例2:
f:id:shoma2da:20151104225155p:plain
出典:GitLab Flow | GitLab

Gitlab flowはイメージとしては「GitHub flow + リリースに必要なブランチ」です。
masterブランチでリリースに向けた作業が終わった段階で上記図のようにproductionブランチやpre-productionブランチにマージを行いリリースの調整やリリース作業を行います。

図では省略されていますがmasterブランチに対する変更はGitHab flowと同じようにPull Requestをする形で気軽に行いましょう。

メリット

リリースに対してかなり柔軟に対応できます。
上記の図のpre-productionブランチ / productionブランチのように徐々に本番に近づけていくような形もブランチで可視化しながら進めることができます。
環境が増えるようであってもブランチを一つ足すだけで済むでしょう。
これはアプリであっても同じでリリースapk作成用、Apple審査対応用、社内配布用、本番用といった環境やリリース段階に応じた柔軟な運用ができます。

また細かい話ではありますが作業のマージ先はGitHub flowと同じく常にmasterブランチです。
git flowのような戦略を取っているとどうしても操作ミスで意図していないブランチにPull Requestを送ってしまうのですが、そうした心配もかなり少なくなります。

そのほか常にリリース関連のブランチは常に存在しているのでそれぞれに応じたCIも設定しやすいでしょう。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

まとめ

バージョン管理戦略の中で最近お気に入りのGitlab flowについて他の戦略と比較しながら紹介しました。
リリースまで含めた作業を考慮しやすいGitlab flowはアプリの開発においても適合しやすいのではないかと思います。

最後に、この記事ではGitlab flowをおすすめしましたが当然のことながらバージョン管理戦略に正解はないです。
実際の現場でのリリースや開発の進め方をよく考えた上でどのフローを選ぶか、選んだフローをどうカスタマイズしていくかはその時々考える必要があるでしょう。
提唱されている戦略の形にとらわれすぎずに効率よくかつ気分よく作業できることを目指しましょう!

*1:masterでそのままリリースを作業を行う方法もありますが、リリースしたコミットの確認をタグでしか行えなくなってしまいコミットツリーから判断しづらくなってしまいます