なぜdevelopブランチは必要なの？

「Gitのブランチ構成どうしましょうか？」
「とりあえずdevelop切ってやっていきますね。」

そのdevelopブランチ本当に必要でしょうか。
developブランチだけ使われていて、masterが全く使われていなかったりしないでしょうか。

よく聞かれるブランチ戦略としてはgit-flowやGitHub Flow、、GitLab Flow等があります。
git-flowにおいてはdevelopやhotfix、releaseといったブランチがありますが、GitHub Flowにはmasterブランチと機能開発ブランチの2つしかありません。GitLab Flowはmasterを中心に開発を行い、productionブランチを安定させていくスタイルです。

実際に新しいプロジェクトを始めるとしたら、どの構成が良いのでしょうか。
今回はカウルを開発するにあたり採用したブランチの構成とその背景について紹介します。

望んでいたこと

前提としてカウルのプロジェクトを始めるにあたって望んだことは以下の3つです。

1. ロールバックによるバージョン戻しが容易であること
2. 問題が起きた場合にバージョン間の問題の切り分けが容易であること
3. 時間のかかる機能開発中にもバグ修正コミットを差し込めること

1と2については、リリース時にタグをつけておくことで容易にgit resetやgit diffが出来ます。

3つ目の要件については、developブランチがあるとよいと考えました。

実際のブランチ構成

上記を踏まえると、タグづけとdevelopブランチはあると良さそうです。
よってカウルでは以下の構成をとりました。

• master
  • テストで確認されたdevelopだけがgit merge --no-ffコマンドでマージされる
  • 急ぎのバグ修正(hotfix)は、確認された後developブランチを経由しない
  • リリース時に自動で”日付_インデックス”tagを付ける(たとえば”20160622_01”)
• develop
  • masterから派生したブランチ、featureブランチの派生元
• (feature/)チケット番号
  • developから派生した機能開発全般のブランチ
• (hotifix/)チケット番号
  • masterから派生したバグ修正用のブランチ

現状、featureやhotixといった修飾は特につけておらず、概念だけメンバー間で共有しています。

実際の開発フロー

考えた構成を基に以下のような流れで開発を行っています。

1. 最新のdevelopからチケット番号でブランチを切る
2. チケット番号ブランチで開発した機能をコミット、プッシュする
3. 終わったらdevelopにプルリクエストを送り、レビューの後マージされる
4. ステージング環境に最新のdevelopを出して確認する
5. 問題なければdevelopをmasterにマージしタグ付け、 本番に最新のタグをデプロイする

カウルの構成でもdevelopは必要なのか

1ヶ月程度かかるような大きめプロジェクトがあり、 他の機能開発も行っているので今のところはあるとよいと考えています。

また一方で以下の変化を踏まえて、よりgithub-flowに近い構成でも問題ない状況になりつつあると考えています。

• コードはすぐにリリースできる状態になっており、日に何度かリリースされることもあり、masterとdevelopの間で違いが少なくなっている
• 開発初期に比べてコードのベースはできていて、小中規模機能や他の箇所への影響が少ない開発が多くなっている

いつdevelopブランチは必要なの？

数日~1週間でブランチがマージされていく状況であればdevelopはなくても問題ないでしょう。シンプルな構成の方がGitの操作も少なくて済みます。
数週間を越えてブランチがマージされないような状況を開発をしているときはdevelopやreleaseがあると安定したプロダクトを出荷できると考えます。

今回はカウルのGitブランチ管理について紹介致しました。
ユーザに素早く安定した価値を届けらる、開発者にも優しい運用にするべく今後も取り組んでいきます！

by まっくす