※私的メモ
git-flow,GitHub Flowは「Gir/GitHubのワークフロー」であり、厳密な規則ではない。
開発規模や人数によって適切なワークフローを用いることで、複数人でのバージョン管理システムの運用を円滑にすることができる。

git-flow

「git-flow」はVincent Driessen氏の「A successful Git branching model」を基にしたワークフロー。
他のワークフローと比べると大規模で複雑な構成になっている。
開発者が4人以上の場合に適している。

ブランチの種類と用途

メインブランチには「master」と「develop」の2つのブランチがある。
これらのブランチは常に存在する。

リリース済みのソースコードを管理する

開発中のソースコードを管理する

タスクごとに「feature」「release」「hotfix」のいずれかのブランチを作成し、作業を行う。

1,developブランチを作成
master(main)ブランチからdevelopブランチを作成

2,機能を実装する
developブランチから、featureブランチを作成
機能実装後、コミットはfeatureブランチに対して行う

3,機能実装を完了する
featureブランチでの作業が完了したら、featureブランチをdevelopブランチにマージする
マージ完了後にfeatureブランチを削除する

4,リリース準備を始める
機能実装が終わりリリースできる状態になったら、developブランチからreleaseブランチを作成する

5,リリース準備を完了する
リリースブランチでの作業が完了したら、releaseブランチをmasterとdevelopブランチにマージする
マージ完了後にreleaseブランチを削除

6,緊急の修正作業を開始する
リリース後に緊急の修正作業が発生した場合は、masterブランチからhotfixブランチを作成し、修正作業を行う
マージ完了後にhotfixブランチを削除する

「GitHub Flow」は「GitHub」の開発で使用されているワークフローであり、「git-flow」に比べてシンプルな構成になっている。

開発人数が1~3人で1日に複数回デプロイを行うようなWebアプリケーションの開発に適している。

1,開発作業を行う
GitHub Flowでは、全てのブランチをmasterブランチから作成する
ブランチ名は、何の作業を行っているかが分かる名前にする。また、作業用ブランチは定期的にリモートリポジトリにプッシュするようにする。これによって、他の開発者の作業状況を把握できるようになる

2,Pull Requestを行う
作業用ブランチをmasterブランチへマージできる状態になったら、プルリクエストを作成して他の開発者にコードレビューを依頼する。そして、プルリクエストが承認されたらmasterへマージする

GitHub Flowを使用した開発では、プルリクエストを積極的に活用する。作業完了後のコードレビューだけではなく、作業途中の実装への助言を求める場合などにも使える

3,デプロイする
masterへのマージが完了したら直ちにデプロイを行う

git-flowは4人以上での開発の際に用いる
GitHub Flowは1~3人での開発に用いる
マージの際はPull Requestをする(GitHub Flowの場合は作業途中でも有用なため積極的にする)