git-flow (Git ブランチモデル)

Tags:

• Git
• SCM
• VCS

git flow

git-flow は、2010 年に Vincent Driessen が書いた「A Successful Git Branching Model」というブログ記事で提案されたブランチ戦略である。

各ブランチの使い方は次のとおりである。

1. メインブランチ: 中央リポジトリと、それを clone した各開発者のリポジトリが依存する中心的なブランチ。
   • master
     • リリース用ブランチ。リリースするたびにタグを付与する。
   • develop
     • 開発用ブランチ。リリース前の最新バージョン。
2. サポートブランチ: 原則として各開発メンバーのリポジトリだけに存在し、役割が終わると削除される短命なブランチ。
   • feature
     • develop から派生し、特定機能の開発のために作成されるブランチ。機能開発が終わると develop にマージされ、削除される。
   • release
     • develop から派生し、リリース準備のために使うブランチ。リリース準備中に不要な feature が入り込まないようにするために作られる。
     • リリースが終わると master と develop にマージされ、その後削除される。
   • hotfix
     • 主にリリース済み製品で障害が発生した場合に緊急で作成されるブランチ。master から直接派生し、バグを修正した後 master にマージされてタグが付与される。
     • また、バグ修正が後から漏れないように develop にもマージする。リリース作業中で release ブランチが存在する場合は、そこにもマージする。

よりシンプルに 1 ブランチで運用する場合:

1. master は常にデプロイ可能である。
2. 新しく何かを進めるときは、master から直接ブランチを作成する。
3. 作成したブランチはローカル環境にコミットし、リモートリポジトリにも同じ名前のブランチとして定期的に push する。
4. 開発が完了したら master に Pull Request を送る。
5. Pull Request が検証されたら master にマージし、すぐに環境へデプロイする。

• Pull Request が検証された後すぐにマージしてデプロイするため、Pull Request を送る前にテストが完了している必要がある。手動テストでも自動テストでもよい。
  • master は常にデプロイ可能でなければならない。マージされるということは、すぐにデプロイ可能であることを意味する。

Git branch network

主要 Branch

ブランチ名	分類	説明
work	メインブランチ	すべての作業ブランチは work ブランチへ統合され、そこから分岐する。 このブランチは削除できない、プロジェクトのすべての作業ソースを含むメインブランチである。
develop	デプロイブランチ	dev 環境へのデプロイ用 branch。
test	デプロイブランチ	test 環境へのデプロイ用 branch。
master	デプロイブランチ	pre、live 環境へのデプロイ用 branch。
feature/	作業ブランチ	新規開発用ブランチ。
bugfix/	作業ブランチ	不具合修正用ブランチ。
hotfix/	作業ブランチ	緊急修正用ブランチ。
release/	デプロイブランチ	Custom デプロイ用ブランチであり、work ブランチ上ではデプロイできない状況、たとえば cherry-pick による選択的デプロイ時に使う。

• メインブランチ (work) は PR merge だけを許可するポリシーであり、作業ブランチで作業した内容は必ず Pull Request を通じてメインブランチへ統合する。
• デプロイブランチ (develop, test, master) はいつでも削除でき、目的のデプロイコミット時点から新しく作成できる。
• 作業ブランチ (feature/, bugfix/, hotfix/) は、メインブランチへ PR された後は削除対象ブランチになる。

Branch ポリシー

すべての作業ブランチは Jira issue と連携していなければならない。

Jira issue 管理連携プロセス

1. Jira issue を作成する。
2. 分岐点を作る。Jira issue タグを自動生成する。
   • 例: feature/PROJ-1
3. コミットメッセージに Jira issue 番号を付けて自動連携する。
   • 例: feat(PROJ-1): project init
4. 作業完了後、work ブランチへ pull request を送る。
5. 作業ブランチを削除する。

Rebase ポリシー

作業ブランチからメインブランチへ PR する際は、必ず rebase work によって base を work の最新位置へ変更し、1 つのコミットに統合して PR を進める。

(git rebase -i: コミット統合機能)

Rebase を必須にする理由

• ブランチネットワークをきれいに保つ。
• メインブランチへ merge する前に、作業者が自分で conflict を解決して PR を進められる。
• 機能ごとに 1 commit とすることで、1 cherry-pick が 1 機能であることを保証できる。
• 多くの作業者が同時に作業しても、ブランチモデルをシンプルに保て、新しい作業者にとっても学習コストが高くならない。
• グラフがきれいで単純になり、コードの流れの把握や明確なデプロイ時点の決定が容易になる。

Pull Request ポリシー

• 作業ブランチを作成する。
• 作業ブランチで開発する。
• 開発完了後に rebase (git rebase -i) し、その過程で conflict を解決し、1 つのコミットに統合する。
• メインブランチへ PR する。
• コードレビューを行う。Default reviewer は 1 名。
• 作業者が直接 PR を承認する。
• メインブランチへマージ済みの作業ブランチは削除する。

コミットメッセージ規則

Git commit message convention。

共通事項

• subject
  • 必須事項であり、コミット内容を簡潔に整理して書く。
• body
  • 任意事項であり、追加情報が必要な場合に書く。
• footer
  • 任意事項であり、影響範囲、たとえば PC/MW/APP を書く。
  • または、追加で tracking が必要な情報や関連 issue key を書く。

ブランチ分類別

type	branch name	msg convention	remarks
feature	feature/{ISSUE-KEY}*	feature(ISSUE-KEY): subject body footer	新機能追加。
bugfix	bugfix/{ISSUE-KEY}*	bugfix(ISSUE-KEY): subject body footer	QA 中に修正が発生した場合。
hotfix	hotfix/{ISSUE-KEY}*	hotfix(ISSUE-KEY): subject body footer	運用中に障害による修正が発生した場合。
release	release/{ISSUE-KEY} または release/yyyymmdd/{ISSUE-KEY}	release: subject issue-key-list body footer	デプロイ時点を表記する場合。
docs	docs/*	docs: subject body	文書類を修正する場合。例: Javadoc, README.md。
refactor	refactor/*	refactor: subject body	コードリファクタリングを行う場合。
test	test/*	test: subject body	テストコード、リファクタリングテストコードを追加する場合。
config	config/*	config: subject body	設定ファイルを修正する場合。例: *.config, *.properties, *.yml。