ブランチ構成について

投稿日：2022年10月2日更新日：2022年10月6日

gitのブランチ構成などについて少しまとめてみようと思います。

Contents

開発者が作成する個別の開発ブランチ。滞留期間は基本的に1日〜１週間程度など短い期間になることが一般的です。ブランチ名は実際にはタスク管理ツール(Redmine、GitHub、Backlog)のチケット番号やIDなどが付与されることが一般的です。

バグの場合はhotfixブランチなどと言う場合もありますね・・・

メインの開発ブランチになります。基本的にはfeatureをこのブランチにマージしていくのが日常の開発の流れになるでしょう。

staging環境へ展開されるブランチ。

読んで字の如く本番環境へ展開されるブランチです。

一番一般的なのは以下のような流れでしょうか。

develop←feature 個別のブランチを終えて、開発ブランチへのマージを行いたいとき

staging←develop 開発での検証が済んでstagingへのリリースを行いたい時

production←staging ステージング環境での検証が済んで本番へのリリースを行いたい時

実際に私が体験した中ですと、以下のようなフローを挟んでいるプロジェクトもありました。

develop_xxxx←feature

develop←develop_xxx

これはかなり一般的なパターンだと思いますが、開発チームが複数あってAチームがdevelop_A、Bチームがdevelop_Bにまずマージをして、その後、developにマージするといったパターンです。

例えばリリース日が決まっており、コードの締切などを厳密に決めたい時などは以下のような運用にしてます。

release-xxxxxx(日付や第何週のような日時がわかるもの)←feature

develop←release-xxxxxx

featureからdevelopに直接入れない理由ですが、今週と来週分のブランチを分けたい場合など(来週分の修正だが今週には入れたくない、日付の関係で入れられない場合)、developだと融通が効かないため上記のようにしたことがあります。