GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します

こんにちは！テニスはじめました、小山です。開発部門でウエディンググループのリーダーをやっています。

今回は私が考えた新しいGitのブランチモデル「GitFeatureFlow」についてお伝えしたいと思います。

GitFeatureFlowとは

Gitを使った開発をより快適にするため、GitFlow,GitHubFlow,GitLabFlowではない、新しいGitのブランチモデル「GitFeatureFlow」を考えました。

Gitを利用して開発を行う場合、Gitのブランチモデルをどうすべきか悩むことが多いかと思います。私自身もこの悩みに直面しました。既存のブランチモデルでは問題が解決できなかったので、GitFeatureFlowという新しいブランチモデルを考え、ウェディンググループに導入。今では快適にGit開発を行っています。

GitFeatureFlowで使う主なブランチはこの3つです。

• master：本番環境にリリースするブランチ

• feature：案件ごとにmasterから切ったブランチ

• test-env（もしくはstg-env）：テスト環境と（stg-envはステージング環境と）同期されているブランチ

このブランチモデルの特徴は下記の通りです。

1. 改修案件ごとにfeatureブランチをひとつ割り当て、テスト環境と同期されているブランチに対して個別にfeatureブランチをマージする (GitFlowは複数のfeatureブランチを含んでいるdevelopブランチをマージする)

2. 各featureブランチは独立しているため、急なリリースの発生、リリース日変更にも対応しやすい

もしよかったら、内容をまとめたSlideShareを見てみてください。

Git Feature Flow!Git Flow,GitHub Flow,GitLab Flow doesn't use it! from naoki koyama

まだ、よくわからない方も多いと思いますので、これから先は私自身の体験をご紹介しながら、GitFeatureFlowのことをお伝えしていきます。

GitFeatureFlow誕生の背景

私がぐるなびに入社した2014年時点、ウエディンググループではGitではなくSVNを使っていました。

そこでSVNからGitへの移行時に、どのブランチモデルを選ぼうか考えました。

ウエディンググループの改修案件の規模は大小さまざま。HTML上の表示文言を変更するという小さいものから、半年かけて機能修正を行うような大規模なものまであります。それら複数の案件が同時に走っており、基本的に毎日リリースが行われている状況です。

そのため、毎日リリースするスタイルに向いていないGitFlowはそもそも論外（毎日featureブランチを作成し、masterブランチとdevelopブランチへのマージ後に削除をするのは骨の折れる作業です）。私自身はワークフローがシンプルなGitHubFlowを希望していました。 ただ、ぐるなびでは品質向上のために、開発後に「品質管理室」という開発とは別チームがテストを実施してから本番環境へのリリースをしています。そのため、開発規模にもよりますがテスト実施からコード修正までにかかる期間は2〜3週間。短期間でのテストとリリースを想定しているGitHubFlowのスピード感では対応できず、断念しました。

GitFlowでもダメ、GitHubFlowでもダメ。

なら、自分で作ればいいじゃない！！……という流れでGitFeatureFlowが誕生しました。

GitFeatureFlowと他のgitブランチモデルとの違い

GitFeatureFlowは前述の通り、featureブランチが中心となって、反映させたい環境用のブランチにマージしていくだけのシンプルなブランチモデルになっています。

また、大小どんな規模の案件や緊急リリースが混在していても、featureブランチが独立しているため、他のブランチとのリリース日を気にする必要がないように考えてあります。

あくまで私見ですが、各gitブランチモデルを比較してみました。

GitFeatureFlowは、現在GitFlowを使っている人や、GitHubFlowで開発を行いたいけど、修正から本番リリースまでの間に時間が掛かってしまうようなチームの方にもおすすめなので、一度お試しください。

実際に運用してみた感想

ウエディンググループではこのフローを導入してから、3年弱、2500回以上リリースを行ってきましたが、このフローが原因でのバグは一度も出ていません。1年がかりのプロジェクトから1時間ほどで仕上げる緊急リリースまで、問題なく行えています。

複数案件を同時に開発していても、他の案件を気にする事なく、リリース日を変更できる快適さがたまりません。

GitFeatureFlow導入後は企画担当者とのコミュニケーションがスムーズになった

1番よかった点は意外にも!?、案件を考えるディレクターとの仲がよくなったことです。 今までのSVNやGitFlowを採用した場合、複数案件を同時に開発するのもリリース日の変更をするのも容易ではありませんでした。そのため、ディレクターは1つの案件で要件を満たす必要があり、優先度の低い機能も盛り込まざるを得なくなっていました。 もちろん開発としては優先度の高い機能から開発したいので、討論になることがありました。

一方、GitFeatureFlowは、複数案件を同時に開発するのが容易なので、複数フェーズに分けてリリースするのが可能になりました。そのため、優先度の高い機能だけをリリースし、優先度の低い機能は検討するということもでき、ディレクターと開発の双方が納得した状態でリリースできるようになりました。

おわりに

今回は新たなGitのブランチモデルを紹介させて頂きましたが、疑問や質問などあればSlideShareにコメント頂ければと思います。

また、私達のチームはDevOpsを実現するために創意工夫を行い、開発・運用効率化を行っております。DevOpsは費用対効果を高めるだけではなく、開発自体を楽しく快適なものに変えてくれます。これからも少しでも誰かの役に立てるような情報を提供していけたらと思います。

お知らせ
ぐるなびでは一緒に働く仲間を募集しています。

小山

26才でヒトのがん遺伝子の研究職を辞め、IT業界に飛び込み、溺れる。。。しんどい想いを何度も経験し、33才でぐるなびに入社。36才でテニスをはじめ、現在ハマり中。可愛い可愛い2児のパパ。