📌

ブランチの構成

2024/07/26に公開

開発でなんとなく使っていたブランチ構成はどのように設計されているのか改めて確認してみました。
今回は「git-flow」というブランチモデルを参考にブランチ構成について学習していきます。

Git Flow
参照:https://nvie.com/posts/a-successful-git-branching-model

ブランチの種類

git-flow は 2 種類のメインブランチ ( master , develop ) と 3 種類のサポートブランチ ( feature , release , hotfix )を利用します。

メインブランチ

開発の軸となるブランチ

master ブランチ

運用方法:大元のブランチの常に本番にリリースできる状態を保つブランチ
ブランチ名:develop

備考
直接コミットは行わない
release 、hotfix からマージを行い、タグを作成する

develop ブランチ

ブランチ名の例:develop
運用方法:masterからブランチを切り開発中の最新状態を反映するブランチ
ブランチ名:develop

備考
基本、直接コミットは行わない
feature , hotfix からマージを行う

サポートブランチ

メインブランチでの開発を補助するためのブランチ

feature ブランチ

運用方法:新機能の開発orバグフィックスを行うのに用いる
  developからブランチを切りdevelopへマージする
ブランチ名:feature/{タスクor案件番号}__*

備考
新機能の開発を行うのに用いる
develop へマージする際は、Git の -no-ff オプションも活用する
(一連のコミットを 1 コミットにまとめる機能)
リモートへ Push せず、ローカルでのみ利用する

release ブランチ

運用方法:developからブランチを切りmasterとdevelopにマージする
ブランチ名:release/ver***.YYYYMMDD

備考
リリースの準備作業を行うのに用いる
バージョンの変更
小さなバグフィックス
master へマージ後、 develop へマージする
完了後、release を削除する

hotfix ブランチ

運用方法:緊急のバグフィックスを行うのに利用する
  masterからブランチを切りmasterとdevelopにマージする
ブランチ名:hotfix/{タスクor案件番号}__*

備考
master へマージ後、develop へマージする
完了後、hotfix を削除する
利用用途としては release に似ているが、
develop を経由せずに master へマージできるため
進行中の開発が影響を受けにくい

Discussion