- ブランチモデルとは、ブランチの名前の付け方、いつ作成し、いつマージするか、という運用方法のガイドライン
- ブランチの命名規則や運用ガイドラインがあると、ローカルブランチを整理しやすくなる
- リモートブランチの名前から、なんのためのブランチかを推測しやすくなる
main / master †
ブランチの保護 †
Git-flow †
mainブランチ †
- git-flowでは main ブランチに直接コミットすることはなく、マージを行うだけのブランチになる
- 誤って直接コミットしてしまわないように注意
developブランチ †
- develop ブランチは、開発の中心となるブランチ
- 開発中は develop ブランチからブランチを切って、作業完了後に再びマージするという作業を繰り返すことになる
- main ブランチ同様、直接このブランチにコミットすることはないので注意
- リポジトリを新規作成したときに、main ブランチから develop ブランチを切っておく
featureブランチ †
- feature ブランチは、機能の追加や変更、バグフィックスを行うブランチ
- ひとつの変更に対してひとつの feature ブランチを切ることになるため、開発中で最も使われるブランチになる
- ブランチの名前は、変更の内容がすぐに分かるような名称にする
- develop ブランチから派生させ、作業完了後に再び develop ブランチにマージする。そして、マージ完了後に削除するというのが一連の流れになる。
releaseブランチ †
- release ブランチは、その名の通り製品をリリースするために使うブランチ
- 製品のリリース時には、関連する作業が必要になる場合が多いでしょう。そういった作業は、develop ブランチから release ブランチを切って、そのブランチでリリース作業を行います。
- リリース作業が完了したら、main ブランチと develop ブランチにマージして、main ブランチのマージコミットにリリースタグ（バージョンなど）をうちましょう。その後、release ブランチは削除します。
hotfixブランチ †
- 製品のリリース後に不具合が見つかった場合は main ブランチから直接 hotfix ブランチを切って緊急の修正を行う
- 修正完了後に main ブランチと develop ブランチにマージして、リリースタグ（マイナーバージョンなど）を打ち、その後 hotfix ブランチを削除する
- 派生元が main になるだけで、操作的には release ブランチと同様
supportブランチ（オプション） †
- プロジェクトによっては不要ですが、旧バージョンをサポートし続けなければいけないプロジェクトでは support ブランチが必要になる
- support ブランチでは、旧バージョンの保守とリリースを行う
- サポートが必要なバージョンの main ブランチのコミットから派生させ、サポートが終了するまで独立してバグフィックスやリリースを行う
mainブランチ †
- 現在の製品のメインブランチ
- 常にデプロイ可能な状態
featureブランチ †
- 新しい作業を開始するときに、わかりやすい名前のブランチをmainから分岐
- ローカルでコミットして、同じ名前でリモートにもpush
- フィードバックやヘルプが必要なとき、またはマージの準備ができたらプルリクエストを作成
- 他のメンバーがレビューして確認したら、mainへマージする
- mainにマージしたらデプロイできる
トランクベース開発 †
フィーチャーフラグ †
その他 †
|
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
