git-flow,GitHub Flowは「Git/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の場合は作業途中でも有用なため積極的にする)