• ブランチモデルとは、ブランチの名前の付け方、いつ作成し、いつマージするか、という運用方法のガイドライン
  • ブランチの命名規則や運用ガイドラインがあると、ローカルブランチを整理しやすくなる
  • リモートブランチの名前から、なんのためのブランチかを推測しやすくなる

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 ブランチのコミットから派生させ、サポートが終了するまで独立してバグフィックスやリリースを行う

GitHub Flow

mainブランチ

  • 現在の製品のメインブランチ
  • 常にデプロイ可能な状態

featureブランチ

  • 新しい作業を開始するときに、わかりやすい名前のブランチをmainから分岐
  • ローカルでコミットして、同じ名前でリモートにもpush
  • フィードバックやヘルプが必要なとき、またはマージの準備ができたらプルリクエストを作成
  • 他のメンバーがレビューして確認したら、mainへマージする
  • mainにマージしたらデプロイできる

GitLab Flow

トランクベース開発

フィーチャーフラグ

その他


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2023-04-25 (火) 10:38:32 (565d)