ぎっとふとーとぎっとはぶふろー

実は Gitflow も GitHub flow も大好きな自分です。

今回は備忘録がてら、各々の flow のブランチについてアホみたいな説明を書き残していこうと思います。

Gitflow のブランチ

今回は以下のようにブランチを書き分けます。

• master
• hotfix
• release
• develop
• feature

master ブランチ（Gitflow）

すべての元となるブランチ。

production 環境であることが多く、直接触ってはいけない。

更新されるごとにタグを切るっぽい。

hotfix ブランチ（Gitflow）

production 環境でバグが見つかった際に切るブランチ。

切らないに越したことはないが、世の中そんなにうまくいかない。

hotfix ブランチがたくさん切られるプロジェクトはスムーズに進んでいない印象を受ける。

release ブランチ（Gitflow）

リリース用のブランチ。

staging 環境であることが多く、バグが見つかった際は直接触る。

hotfix ブランチで修正する前に release ブランチで食い止めたい。

develop ブランチ（Gitflow）

基本的な開発の元となるブランチ。

development 環境であることが多く、master ブランチ同様直接触ってはいけない。

feature ブランチ（Gitflow）

開発用のブランチ。

開発用のローカル環境であり、もっともお世話になる。

各々の feature ブランチが大きいプロジェクトはスムーズに進んでいない印象を受ける。

Gitflow 採用時の留意点

• シンプルだけど複雑、きちんとブランチの状態を把握できるエンジニアが必要
• hotfix ブランチを develop ブランチに向けることをつい忘れる、GitHub だとやりづらい
• 複数の環境が容易しやすいので、段階的にテストを行いやすい

GitHub flow のブランチ

今回は以下のようにブランチを書き分けます。

• master
• feature

master ブランチ（GitHub flow）

元となるブランチ。

production 環境であることが多く、直接触ってはいけない。

feature ブランチ（GitHub flow）

開発用のブランチ。

開発用のローカル環境である。

GitHub flow 採用時の留意点

• これ以上ないほどシンプル、迷ったらまずは GitHub flow
• アジャイル開発との親和性が高くイケイケドンドンで進むので、意外と上級者向きな印象
• 複数の環境を用意しなければいけないケースには不向き

個人的な見解

どちらも素晴らしいフローだと思っているのですが、やはり GitHub flow のほうがシンプルゆえに容易かなーという印象です。

ただお硬いプロジェクトや大規模なプロジェクトで GitHub flow は結構怖いので、ケースバイケースであることは言わずもがなです。

本番環境にリリースするまでは GitHub flow でガンガン進めていって、ファーストリリース後は状況によってフローを切り替える、とかも全然アリかなーと思います。

ただし GitHub flow → Gitflow は容易であっても、Gitflow → GitHub flow の切り替えは結構勇気がいる印象…。

いずれにせよ、feature ブランチを小さく持つことが大切だと個人的には思います。

あとは ci できちんとテストを回せれば言うことなしかと。