배달의 민족(우아한 형제들) 開発ブログの内容を参考に作成しました。
1.定義
プロジェクトを進めるにあたって、ブランチ管理を有効にするブランチ別の役割を区分しておいた概念を適用させたものである。
2．図式化の画像(ネット検索）
３．BRANCHの役割
１）develop
developブランチは、名前からも分かるように開発に対するブランチである。 開発の進行はdevelopブランチで行われ、全般的なすべての開発がここで行われる。
２）feature
フィーチャーブランチはdevelopブランチから派生するブランチである。 フィーチャーブランチは、developの小単位開発だと考えればいいが、特定機能/関数などで大きさはユーザによって異なる特定機能を開発するためのブランチだと考えればよい。
すなわち、基本開発はフィーチャーブランチで進められるが、該当機能を統合してボトルネック現象の解決をするところがdevelopブランチだと考えればよい。
各機能別開発のためのフィーチャーブランチを取って機能を開発し、該当機能開発が完了すれば、developブランチに併合して他のフィーチャーとのボトルネック現象やバグなどを解決することをdevelopブランチで進めることである。
３）release
releaseブランチは、プロジェクトの開発が完了し、配布を進める過程のブランチである。 当該ブランチでは大きくリリースノートの作成、documentationの作成等と配布のための配布版の準備等を進める。
４）master/main
masterあるいはmainブランチは、配布版に対する内容が保存されるブランチである。 該当ブランチにはtagというものを付けて配布(リリース)バージョンを表示し、該当バージョンのトラッキングをすぐに進めることができるブランチだ。
５）hotfix
hotfixブランチは、masterまたはmainブランチに配布を進めたが、予期せぬバグが発生した場合、mainブランチからhotfixブランチを派生する。
hotfixという部分は、通常、セキュリティ上の深刻な脆弱性が発見されたり、ビジネスロジック的に多くの損害が発生しうるバグが発生した時、つまり今すぐ直さなければならないバグが発生した時に使用するブランチである。
（このようなバグはdevelopブランチで先に確認し、なくさなければならず、遅くともreleaseブランチで配布前にもう一度最終点検を通じてバグが発生しないようにしなければならない。)
しかし、このようなバグが絶対に発生できないと仮定できないため、もし発生した場合、hotfixブランチを通じて迅速に解決しなければならない。
６）bugfix
上記の図にはないが、gitflowシステムで存在するブランチが一つ存在する。 まさにbugfixというブランチだが、内容はhotfixとほぼ似ている。 ただしmaster/mainブランチではなくdevelopブランチから派生するという点がhotfixと異なる。
すなわち、developブランチでフィーチャーを併合して開発を進めたが、併合で誤ったコードが一緒に合わされたり、色々なフィーチャーを合わせて発生しうるバグをこのbugfixブランチを通じて解決することだ。
直ちに配布が行われたのではなく、開発過程の中で発生したバグであるため、hotfixよりは優先度が低いブランチだ。
3．使用方法
１）git flow init
gitflow管理形式で適用するというコマンドである。 最も基本設定として適用するには、-dオプションを与えればよい。
（当然、最も基本的な設定が使いやすく、branchの名前も直観的だ。 -dオプションを付けなければ、本人が直接各役割別branchの名前を付けなければならない。
git flow init-d
gitflowinitをすると、基本的にdevelopブランチにcheckoutされているだろう。 目に見えるブランチはmaster/mainとdevelop branchが存在する。
２）feature branch
各機能別開発のためにフィーチャーbranchを始めてみよう。
#feature branchスタート
git flow feature start
#feature branchdevelopブランチに併合·削除
git flow feature finish
#feature branch遠隔リポジトリに同期化
git flow feature publish
使い方の上と同じである。 name>部分に自分の好きなbranchの名前を付ければいい。 通常は当該フィーチャーで開発を進める機能についての簡単なキーワードとして名前をつける。
publishキーワードはブランチを遠隔貯蔵所にpushするのと同じ過程を進めるコマンドである。 ただし、publishを進める際には、必ず現在のプロジェクトに修正事項が残っていてはならない。
- release branch
各機能ごとの開発が終わって配布を進めるrelease branchを作ってみよう。
#release branch スタート
git flow release start
#release branch 終了
git flow release finish
フィーチャーbranchと同じようにstart、フィインishで使用すればよい。
この時、nameには通常配布を進行するリリースバージョンが明示される。
- hotfix branch
#hotfix branchスタート
git flow hotfix start
#hotfix branch 終了
git flow hotfix finish
hotfixはrelease branch と同様にname部分にバージョンが明示される。 配布後に素早くバグを修正して再配布するので、新しいバージョンが生成されるのだ。
- bugfix branch
#hotfix branch スタート
git flow hotfix start
#hotfix branch 終了
git flow hotfix finish
bugfixは配布されたプロジェクトで発生したバグではないため、の部分には希望する名前を入れればいい。 通常はフィーチャーbranchと同様に、どのようなbugを修正するかがわかるキーワードとして明示する。