はじめに

SIとしてGitブランチ戦略を考えた時、何が最適か見つからなかった
- GitHub-flowは都度リリースする形態が前提なので、SIの様にフェーズという長い期間を経てリリースするのに向かない
- Git-flowはdevelopブランチとmainブランチの定義が曖昧、きっちり管理しないとカオスになる
- GitLab-flow, gitworkflows...
運用としては単純明快なGitHub-flowがいいが、SIにおける運用や各ブランチの明確化、CICD運用を踏まえて改良して運用することにした。

概要

mainがメインである
タスク作業はfeature/#{issue番号}で行う
不具合対応はhotfix/#{issue番号}で行う
環境確認用ブランチ(検証: env-staging / 本番: env-production)を用意する
- 各環境にデプロイする際に対象ブランチで上書きし、デプロイする
  上書き元と同一のブランチとしたいため、コンフリクトリスクがあるmergeやrebaseは行わない
```
# STG環境の場合
git checkout env-staging
git reset --hard 上書き元ブランチ
```
- 本ブランチはデプロイするためだけのテンポラリブランチであり、壊れても無くなっても問題ないものとする
- 現在の各環境の状態となる
- ブランチpushによるCICDを行うなら本ブランチをトリガーとする
- 状況により環境ブランチを切る (開発: env-development等)
ファーストリリース前後で運用方法が変わる(下図参照)
- ファーストリリース後のmainは問題なく動作する本番環境と同じもの(受入テストを完了したもの)という扱いとする

mainよりrelease/ver{バージョン番号}を切る- タスク作業をする際は、release/ver{バージョン番号}からfeature/#{issue番号}を切る
- タスク完了後、release/ver{バージョン番号}へマージする
不具合修正が生じたら、mainからhotfixを切る
- 修正後、env-staging, env-productionへ上書きし各環境にデプロイ、動作確認する
```
# STG環境の場合
git checkout env-staging
git reset --hard hotfix/#***
```
- 本番の動作確認完了後、masterへマージする
- 開発中のrelease/ver{バージョン番号}へマージする
リリース時
- release/ver{バージョン番号}をenv-staging, env-productionへ上書きし各環境にデプロイ、動作確認する
```
# STG環境の場合
git checkout env-staging
git reset --hard release/ver{バージョン番号}
```
- 本番の動作確認完了後、mainへマージする