Gitにおけるリポジトリモデルのことであり、どのようにbranchを切って開発・運用していくのかというワークフローの話。 github flowはgit flowを簡略化したものであり、スピード感を持って開発運用していく場合には推奨される。ただ、どちらの方が良いということは一概には言えず、開発スピードや開発規模等によってそのワークフローを考える必要がある。
git flow
・masterブランチ - メインブランチで常にリリースできる状態
・developブランチ - メインのブランチでここからブランチを切って開発を進める
・featureブランチ - developから個人別にブランチを切って開発開始
・hotfixブランチ - 緊急のバグなどをmasterからブランチを切って対応
・releaseブランチ - リリース直前用のブランチ
特徴
基本的にはmasterはreleaseからmergeされてデプロイするだけの立ち位置。 developからfeature（開発用）ブランチを切って、開発しdevelopにmergeするという流れ。 リリース前にはdevelopからreleaseブランチへmergeし、その後masterへ。
サービスリリース後にバグ等が発見された場合、迅速な修正が求められ、 そのような時のためにfotfixはmasterから直接ブランチを切り、バグ修正後、masterに直接mergeし、developにも変更を反映させる。
開発の流れ
・masterからdevelopブランチを切り、developからfeatureブランチを切り、それぞれ開発開始。
・featureブランチで作業が終わったらdevelopへmergeする。
・developにはいくつかのブランチ（feature）からmergeされている状態で、リリースする前にreleaseブランチへmergeし、微調整。
・リリースできそうになればreleaseからmasterとdevelopへそれぞれmergeする。
・masterへのマージが完了したらデプロイを行う。
※バグが発生した場合 ・masterから直接ブランチを切る（hotfix）
・hotfixで修正して、masterとdevelopへそれぞれmergeする。
・masterへのマージが完了したらデプロイを行う。
GitHub flow
github flowはgit flowを簡略化したものであり、シンプルな構成になっているため、 1日に複数回デプロイを行うようなスピード感を持ったWebアプリケーションの開発に適している。
開発の流れ
・GitHub Flowでは、全てのブランチをmasterブランチから切り、他の開発者の作業状況を把握できるよう、作業用ブランチは定期的にリモートリポジトリにプッシュする。
・作業用ブランチをmasterブランチへマージできる状態になったら、プルリクエストを作成して他の開発者にコードレビューを依頼し、プルリクエストが承認されたらmasterへマージします。GitHub Flowを使用した開発では、プルリクエストを積極的に活用するのがポイント。
・masterへのマージが完了したら直ちにデプロイを行う。
運用方法まとめ
git flowもgithub flowもそれぞれ良いところがあり、欠点もある。 弊社ではgitt flowとgithub flowの良いところ取りをしているような感覚だ。 基礎となるのはgit flowだが、github flowで用いられるプルリクエストを用いてレビュー改善を行い、masterへのmergeはreleaseブランチを使わずdevelopをそのままmergeするという、必要なところ（開発の確認）には時間をかけ、リリース時にはスピード感を持ってデプロイすることができる良いところ取りだ。 皆さんも会社の開発運用方法の確認と変更の検討をしてみてはどうだろうか。
Комментарии