Gitは簡単にブランチ（branch）を作ることができます。
- ちょっとした実験をするためにブランチを作成します。
- あるIssueのために複数のアイデアがあれば、それぞれにブランチを作ることがあります。
- いつから不具合が発生していたのかを調べるために過去のリリースのブランチを作成します。
- リリースに取り込まれなかったIssueのブランチが残っています。
このように大量のブランチができてしまいます。
feature/ 下に大量のブランチがあると、チェックアウトしたいブランチを探すのが面倒だね。
マージ元のブランチを探すのも大変。本当にこのブランチだったかしら？と心配になるわ。
ブランチの名前の付け方や、整理の仕方のガイドラインってないの？
あります。Gitにはいくつかの有名なブランチモデルがあります。ブランチモデルとは、ブランチの名前の付け方、いつ作成し、いつマージするか、という運用方法のガイドラインです。
ブランチの命名規則や運用ガイドラインがあると、ローカルブランチを整理しやすくなります。リモートブランチの名前から、なんのためのブランチかを推測しやすくなります。
そこで、有名なブランチモデルのgit-flow、 GitHub Flow、 GitLab Flowのブランチ名を調べました。
git-flowはブランチ名の参考に、GitHub Flowは継続的インデグレーションのブランチ運用の参考に、GitLab Flowは本番環境やリリースに合わせたブランチ運用の参考にするといいでしょう。
git-flowモデル
これらの記事では、例として、feature-123 や release-1.2 のように説明されています。SourcetreeやTortoiseGitは、ブランチ一覧をスラッシュ区切りでツリー表示するので、ここでは例として、feature/123 や release/1.2 を使います。
masterブランチ
現在の製品のメインブランチです。originに常に存在します。
developブランチ
次回リリース用のメインブランチです。originに常に存在します。リリース時にmasterへマージします。
featureブランチ
新しい機能を開発するための開発者用のブランチです。Issueの作業を開始するときに、developから分岐して、Issueの作業が完了したら、developへマージします。developへマージしたら削除します。
例：feature/123 （123はIssue番号）
releaseブランチ
次回リリースが近くなったら、developから分岐して、developとmasterへマージします。リリース担当者用のブランチです。リリースしたら、削除します。
例：release/1.2
hotfixブランチ
現在の製品バージョンのバグフィックス用で、開発者ローカルブランチです。masterから分岐して、masterとdevelopへマージします。マージしたら削除します。
例：hotfix/123（123はIssue番号）
GitHub Flowモデル
メインブランチはmasterの１つだけ、常にデプロイ可能な状態に維持するというシンプルなブランチモデルです。プルリクエストを作って、レビューしてもらって、マージします。
masterブランチ
現在の製品のメインブランチです。常にデプロイ可能な状態です。
featureブランチ
- 新しい作業を開始するときは、わかりやすい名前のブランチをmasterから分岐します。
- ローカルでコミットして、同じ名前でリモートにもpushします。
- フィードバックやヘルプが必要なとき、またはマージの準備ができたらプルリクエストを作成します。
- 他のメンバーがレビューして確認したら、masterへマージできます。
- masterにマージしたらデプロイできます。
「わかりやすい名前」としか説明されていませんが、それが難しいんですよね。筆者はIssue番号と合わせて、feature/123 のようにつけています。
GitLab Flowモデル
GitHub Flowのmasterとfeatureの関係はそのままに、masterを本番にデプロイできないケースを考慮しています。
productionブランチモデル
featureブランチ
GitHub Flowと同じ使い方です。masterから分岐して、プルリクエストして、masterへマージします。
masterブランチ
製品のメインブランチです。masterにマージするタイミングで、本番環境へデプロイできるとはかぎりません。本番環境へデプロイする準備ができたら、productionブランチへマージします。
productionブランチ
本番ブランチです。本番環境にデプロイされます。
環境ブランチモデル
featureブランチ
GitHub Flowと同じ使い方です。masterから分岐して、プルリクエストして、masterへマージします。
masterブランチ
製品のメインブランチです。ステージング環境へデプロイされます。ステージング環境でのテストに合格したら、pre-productionへマージします。
pre-productionブランチ
本番直前環境ブランチです。本番直前環境にデプロイされます。本番直前環境でのテストに合格したら、productionブランチへマージします。
productionブランチ
本番環境ブランチです。本番環境にデプロイされます。
リリースモデル
ソフトウェアを外部にリリースする場合、バージョンごとのリリースブランチで作業する必要があります。
featureブランチ
GitHub Flowと同じ使い方です。masterから分岐して、プルリクエストして、masterへマージします。
masterブランチ
製品のメインブランチです。ステージング環境へデプロイされます。ステージング環境でテストします。
各種のバグ修正は、まずmasterへマージされて、各リリースブランチへcherry-pickされます。
リリースブランチ
各バージョンごとのリリースブランチです。
例：2-3-stable、2-4-stable
その他のブランチ名
その他、筆者が使っているブランチ名です。
pendingブランチ
新しい機能を feature/123ブランチで作業しているとき、その機能はリリースに取り込まないことがあります。すぐにはブランチを削除せずに、しばらく取っておきたいのですが、feature/123のままだと、featureブランチが多くなってしまいます。
そこで、feature/123 から pending/123 にリネームします。
ローカルだけで使います。リモートへpushしません。
例：pending/123
tmpブランチ
いつ削除してもいいブランチ。ちょっとした実験的なブランチ、いつから不具合が発生したのか調べるための過去リリース確認のブランチなど。ローカルブランチを整理するとき、自信をもって削除できます。
ローカルだけで使います。リモートへpushしません。
例：tmp/feature/123、tmp/ver/456
personalsブランチ
Issueを作るほどではないけれど、何人かの開発者がそれぞれが触りたいとき。リモートへpushします。
例：personals/taro/develop
releaseごとのmaster,featureブランチ
ver2の開発しているとき、ver1を修正するケースです。修正したい箇所がver1とver2では大きく違っていて、ver2を修正できないことがあります。
このようなとき、ver1ブランチを作るのではなく、ver1/master、ver1/feature/123 のようにブランチを作って、作業します。
例：ver1/master、ver1/feature/123、ver2/master、ver2/feature/123
