前書き

前にいた現場で git のブランチのルールを書いて、そのやり方で上手くいっていたのだが、別の現場にきて「ちょっとブランチ運用が妙かもしれない」と思った時に、あの時に書いた文章をそのまま出すのは倫理的にはちょっとまずいかもしれないと思った。
(時間外に家で書いてメールで職場アドレスに送りつけたので手元に元がないわけではないのだけど)

という事で、どうせもう一度書くのであれば Qiita にでも書いておけば、以降はそれを使いまわせると思い書いておきます。

単純さと充分な実用性を兼備している方法だと思うので、そのまま適用してもよい、あなたのチームのルールのたたき台として参考にするもよしだと思います。

各ブランチの説明

1. master (main) ブランチの位置づけ

master (main) ブランチは、リリースが完了した「安定した内容」を保持するブランチとします。
当然 master (main) への直接のコミットは禁止ですし、feature ブランチをマージするのもいけません。

2. release ブランチの位置づけ

スケジュールされたリリースに向けて release ブランチを作成します。
release ブランチは master (main) ブランチから切ります。
ブランチ名は release/2024-0426 のように、「リリース予定日」を含めるとよいと思います。
複数の feature ブランチを含めることになるので release ブランチに直接 commit する事は原則禁止とします。

運用を楽にする為のルールとして、「同時に存在していい release ブランチは最大1個まで」とするといいと思います。
将来のリリース予定日が決まっているからといって、release ブランチを二個以上同時に切ってしまうと、コンフリクトが発生する可能性も生じてしまい、誰がコンフリクトを解消するべきかという問題が発生します。

release ブランチには、そのリリースに含める複数の機能の feature ブランチをマージします。(つまり feature ブランチの PR/MR のマージ先は release ブランチとします)

予定された feature ブランチが全てマージされたら release ブランチを QA 環境にデプロイして QA 班に確認してもらい、全ての問題の解消を目指します。

尚、既にマージ済みの feature ブランチのバグ修正分は、feature ブランチを (ローカルリポジトリから) 復活させて再度 PR/MR を新しく出し直すのが良いと思います。
ここで『バグの修正なので直接 release ブランチにコミットしました』を許してしまうと、
担当者本人以外の目を通っていないコードが本番に入る流れとなります。

全ての問題が解消して、リリース予定タイミングを迎えたら本番デプロイを行います。
リリースを表すタグを release-2024-0426-A のような名前で打ち、このタグを指定して本番デプロイを行います。
(何らかの理由で一度で上手くいかず、同じリリースブランチでタグを打ち直す場合は最後のアルファベットを次に進めます)

本番デプロイ直後の10分程度の監視で著しいパフォーマンスの問題や障害報告等がなかった場合はリリース完了とし、リリースブランチを master (main) ブランチにマージします。

例: merge release/2024-0426 to master (main)

もし他の release ブランチが既に存在する場合、それらの relase ブランチにも今回の relase ブランチの変更を反映する必要がありますので、今回の release ブランチから直接マージするか、今回の release ブランチをマージした後の master (main) ブランチをマージします。

3. feature ブランチの位置づけ

個別の機能開発を行うブランチです。
master (main) ブランチから切ります。
feature ブランチの正式なマージ先 (PR/MR で指定するマージ先) は release ブランチです (master (main) ではありません)。

4. hotfix ブランチは?

エンジニアが少人数 (10人程度でしょうか?) の場合は hotfix ブランチの運用せずに「緊急の release ブランチ」で代用する事ができるかもしれません。
(hotfix ブランチを運用する事にしても発生の可能性がある事に変わりはありませんが、これにより release ブランチが複数同時に存在した場合のコンフリクト問題は発生します)

それ以上の人数のエンジニアが関わる事で意思疎通が上手くいかず、hotfix 目的なのに普通の release ブランチ扱いで関係ない feature がマージされてしまうような事が発生するのであれば hotfix ブランチの運用を視野に入れてもよいかもしれません。

hotfix ブランチを運用する場合、hotfix ブランチの意味を考えれば通常は複数の feature が混ざるという事はないと思うので、hotfix ブランチに直接コミットしてもいいかと思います。
もし複数の feature に分かれるような場合は release ブランチと同様に hotfix ブランチには直接コミットしないほうがいいでしょう。
(但しこの時、自分たちが hotfix ブランチの意味に反するような事を本当にしていないか、再考は必要だと思われます)

hotfix もタグを打ち、デプロイを行い、直後の短期間の監視で目立った問題が起こっていなければ master (main) ブランチにマージします。
この時、release ブランチが存在する場合には、release ブランチに hotfix 分の変更を取り込む必要があります。
hotfix ブランチから直接マージするか、hotfix ブランチをマージした後の master (main) ブランチを release ブランチにマージします。
この時 release ブランチへのマージではコンフリクトが発生する可能性がありますが、その場合誰が解決するべきなのかは決めておいた方がいいでしょう。

5. develop ブランチは?

この運用法では develop ブランチは使っていません。「早めの統合」を確認するブランチとして develop ブランチを運用してもいいかもしれませんが、リリースしない事になった内容がゴミとして少しずつたまっていくので、develop ブランチを運用する場合は定期的に破棄して作り直す必要があります。
いっそのこと develop ブランチも develop/2024-04 のように日付入りのブランチ名にして、一定期間専用としてしまうのもいいかもしれません。(期間が過ぎたら廃棄し、master (main) から新たに切り直して、再び各フィーチャーから (PR/MRを経由せず) マージし直してもらう)

まとめ

以上が、単純さと充分な実用性を兼備していると自負している git ブランチ運用方法です。
ほぼここに書いた内容で某アバター着せ替えアプリの git 運用を2年ほどやっていましたが、大きな問題はありませんでした。

チームの規模などにより必ずしもフィットしない部分もあるかもしれませんが、その場合でもたたき台として頂くのにはいいのではないかと思っています。