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

ブランチの保護

Git-flow

masterブランチ

  • git-flowでは master ブランチに直接コミットすることはなく、マージを行うだけのブランチになる
  • 誤って直接コミットしてしまわないように注意

developブランチ

  • develop ブランチは、開発の中心となるブランチ
  • 開発中は develop ブランチからブランチを切って、作業完了後に再びマージするという作業を繰り返すことになる
  • master ブランチ同様、直接このブランチにコミットすることはないので注意
  • リポジトリを新規作成したときに、master ブランチから develop ブランチを切っておく

featureブランチ

  • feature ブランチは、機能の追加や変更、バグフィックスを行うブランチ
  • ひとつの変更に対してひとつの feature ブランチを切ることになるため、開発中で最も使われるブランチになる
  • ブランチの名前は、変更の内容がすぐに分かるような名称にする
  • develop ブランチから派生させ、作業完了後に再び develop ブランチにマージする。そして、マージ完了後に削除するというのが一連の流れになる。

releaseブランチ

  • release ブランチは、その名の通り製品をリリースするために使うブランチ
  • 製品のリリース時には、関連する作業が必要になる場合が多いでしょう。そういった作業は、develop ブランチから release ブランチを切って、そのブランチでリリース作業を行います。
  • リリース作業が完了したら、master ブランチと develop ブランチにマージして、master ブランチのマージコミットにリリースタグ(バージョンなど)をうちましょう。その後、release ブランチは削除します。

hotfixブランチ

  • 製品のリリース後に不具合が見つかった場合は master ブランチから直接 hotfix ブランチを切って緊急の修正を行う
  • 修正完了後に master ブランチと develop ブランチにマージして、リリースタグ(マイナーバージョンなど)を打ち、その後 hotfix ブランチを削除する
  • 派生元が master になるだけで、操作的には release ブランチと同様

supportブランチ(オプション)

  • プロジェクトによっては不要ですが、旧バージョンをサポートし続けなければいけないプロジェクトでは support ブランチが必要になる
  • support ブランチでは、旧バージョンの保守とリリースを行う
  • サポートが必要なバージョンの master ブランチのコミットから派生させ、サポートが終了するまで独立してバグフィックスやリリースを行う

GitHub Flow

masterブランチ

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

featureブランチ

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

GitLab Flow

トランクベース開発

フィーチャーフラグ

その他


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2022-07-04 (月) 09:43:53 (37d)