※私的メモ
git-flow,GitHub Flowは「Gir/GitHubのワークフロー」であり、厳密な規則ではない。
開発規模や人数によって適切なワークフローを用いることで、複数人でのバージョン管理システムの運用を円滑にすることができる。
#git-flow
「git-flow」はVincent Driessen氏の「A successful Git branching model」を基にしたワークフロー。
他のワークフローと比べると大規模で複雑な構成になっている。
開発者が4人以上の場合に適している。
##ブランチの種類と用途
###メインブランチ
メインブランチには**「master」と「develop」**の2つのブランチがある。
これらのブランチは常に存在する。
- master(main)
リリース済みのソースコードを管理する
- develop
開発中のソースコードを管理する
###サポートブランチ
タスクごとに**「feature」「release」「hotfix」**のいずれかのブランチを作成し、作業を行う。
-
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 Flow」は「GitHub」の開発で使用されているワークフローであり、「git-flow」に比べてシンプルな構成になっている。
開発人数が1~3人で1日に複数回デプロイを行うようなWebアプリケーションの開発に適している。
##6つのルール
- masterブランチは常にデプロイ可能である
- 作業用ブランチをmasterから作成する
- 作業用ブランチを定期的にプッシュする
- プルリクエストを活用する
- プルリクエストが承認されたらmasterへマージする
- masterへのマージが完了したら直ちにデプロイを行う
##開発フローの例
1,開発作業を行う
GitHub Flowでは、全てのブランチをmasterブランチから作成する
ブランチ名は、何の作業を行っているかが分かる名前にする。また、作業用ブランチは定期的にリモートリポジトリにプッシュするようにする。これによって、他の開発者の作業状況を把握できるようになる
2,Pull Requestを行う
作業用ブランチをmasterブランチへマージできる状態になったら、プルリクエストを作成して他の開発者にコードレビューを依頼する。そして、プルリクエストが承認されたらmasterへマージする
GitHub Flowを使用した開発では、プルリクエストを積極的に活用する。作業完了後のコードレビューだけではなく、作業途中の実装への助言を求める場合などにも使える
3,デプロイする
masterへのマージが完了したら直ちにデプロイを行う
#まとめ
git-flowは4人以上での開発の際に用いる
GitHub Flowは1~3人での開発に用いる
マージの際はPull Requestをする(GitHub Flowの場合は作業途中でも有用なため積極的にする)
- master(main)・・・ユーザーが使う製品
- hotfix・・・バグ修正用ブランチ、masterからクローンしてくる
- release・・・リリース用
- develop・・・featureブランチの集まり
- feature・・・作業ブランチ
#参考
https://www.atmarkit.co.jp/ait/articles/1708/01/news015.html#02