ブランチ運用の覚書（git）

前提条件

WEBサイト/サービスの開発
2〜7名程度の小規模チーム
Gitの利用にそれなりに習熟している人々で構成されている
GitHubやGitLabなどのリポジトリ管理ツールを利用している

基本はGitHub Flow + Git Feature Flow

基本的な運用方針はGitHub FlowとGit Feature Flowをベースにする
運用に際してGitHub FlowとGit Feature Flowを固守する必要はなく、状況やチームのやり方に合わせて柔軟にルールを変えてもよい

ブランチは4種類（master, task, env, release）

ブランチはmaster、task、release、envの4種類を基本とする
ブランチの具体的な名前はチーム内で合意が取れていれば好きなものを使って構わない（taskをfeatureと呼ぶなど）
それぞれの役割は以下の通り
master:
- リリース可能/リリース済みのコードベースで全てのブランチの基本となる
task:
- 開発テーマ毎に開発を行うコードベース
- 必ずmasterから派生する
release:
- 大きめの変更を行う際、taskをまとめるブランチ
- 開発テーマが小さく、taskが1つのブランチで完結する場合は作らなくてもよい
env:
- 特定の環境と同期しているコードベース（結合試験用の検証環境など）

masterブランチは常に本番環境と同期されていること

masterブランチは常に本番環境にデプロイされたコードベースであること
変更をマージした直後など例外的な状況を除いて、常にmasterブランチ = 本番環境となっていなくてはならない（MUST）
masterブランチへのマージが行われたタイミングで本番環境にデプロイが行われるようCIサーバを設定しておくことが望ましい

developブランチは使わない

developブランチは使わない
GitHub Flowでも使っていない
developブランチはWEBアプリやWEBサービスの開発では有用性が低い
顧客のマシンにインストールするスタイルのアプリケーション（スマホアプリやPCソフトなど）の場合は有用
WEBアプリ/WEBサービスの場合は後述のenvブランチでほぼ全てのニーズを吸収できる

作業時はmasterブランチからtaskブランチを切る

masterからtaskブランチを切り、開発はtaskで行う
taskで実装/テスト/レビューが完了したらmasterへマージする
masterへのマージが完了したらtaskは削除する
masterへ直接コミット＆プッシュすることは禁止とする（リポジトリの設定で禁止しておく）

複数のtaskブランチをまとめる場合はreleaseブランチを作る

原則としては、ひとつの開発テーマ = ひとつのtaskブランチであることが望ましい
しかし、どうしてもひとつの開発テーマに対して、複数のtaskブランチで並行して開発を行いたくなる場面はある
そのような場合は関連するtaskブランチを統合するreleaseブランチを作成し、そこで各taskブランチの成果を統合する
各taskブランチの成果はそれぞれのプルリクでレビューを行うが、releaseブランチも全てのtaskブランチの成果が統合されたタイミングで改めてレビューを行わなければならない（MUST）
レビューとテストに問題なければmasterへマージし、releaseブランチを削除する

検証環境へのデプロイはenvブランチで行う

検証環境へのデプロイは該当の環境と同期するブランチを作成し、そのブランチにマージすることでデプロイを行う
env/develop、env/stagingのような各環境と同期する為のブランチを用意しておき、ブランチが更新されたらデプロイが実行されるようCIサーバを設定しておく
これらのブランチは履歴を積み重ねる必要はなく、かつ様々な変更がマージされることでコンフリクトが発生する可能性が高い
その為、これらのブランチはマージを行うのではなく、ブランチを丸ごと上書きすることで更新を行う
ブランチの更新は↓のように実行する

$ git checkout env/develop
$ git reset --hard task/xxxx
$ git push -f origin env/develop

参考資料