ブランチ運用の覚書（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
参考資料