ブランチ戦略（GitHub Flow）

全員が違う流儀で使うと、履歴は読めなくなる

ブランチの作り方も合流のさせ方も揃いました。ただ、技術が分かっていてもチーム全員がバラバラの流儀で使えば履歴は荒れます。誰がどのブランチをいつ作り、いつ消すか。この取り決めがブランチ戦略です。

ここでは GitHub Flow という型を扱います。覚えることが少なく、学習中の個人開発から実務まで同じ形で使えます。手順はこれだけです。

1. 最新の main から作業ブランチを切る
2. そのブランチでコミットする
3. プルリクエストを出す
4. レビューを受けて直す
5. main にマージして、ブランチを削除する

長く生きるブランチは main ただ 1 本で、それ以外は数日で生まれて消える使い捨てです。

              A---B   feature/login-form
             /       \
  o---o---o-----------M---o   main

1 本の幹から短い枝が生えては戻る。これを延々と繰り返すだけです。枝が幹から離れている時間が短いほど、この形はうまく回ります。

main が信用できないと、出すたびに確認が要る

支えている原則は 1 つです。main の最新は、いつ本番へ出しても壊れない状態でなければならない。

この約束があると、判断が自動的に決まります。main に直接コミットしない。動かないコードをマージしない。緊急の修正も main から切って同じ流れを通し、特別扱いの近道を作らない。

逆に main が信用できないチームでは、リリースのたびに「今の main って出して大丈夫でしたっけ」という確認が発生します。この確認が消えることが、いちばんの見返りです。

習慣に頼らず、仕組みで守れます。GitHub で main にブランチ保護をかけると、プルリクエスト経由でしかマージできなくなります。保護のかかった main へ直接 push すると、こう拒否されます。

$ git push
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes must be made through a pull request.

このときコミット自体は手元に残っています。作業ブランチを切ってそこへ移し、プルリクエストを出し直せば無駄になりません。

前の作業を抱えたまま、次のブランチを切ってしまう

作業ブランチは必ず最新の main から切ります。古い main から切ると、その時点で他人の変更ぶんの遅れを背負います。

$ git switch main
$ git pull
$ git switch -c feature/login-form

やりがちなのは、終わったブランチに立ったまま次を切ることです。feature/login-form の上で git switch -c feature/logout-form と打つと、まだレビュー中の login の変更を丸ごと抱えた logout ブランチができます。プルリクエストに関係ない差分が混ざり、レビュアーが読めません。新しい作業は必ず main に戻ってから切る、と手順を固定してください。

名前は、他人が読んで何をするブランチか分かることが条件です。種類を頭に付ける形がよく使われます。

feature/login-form
fix/header-overflow
docs/setup-guide

wip や tmp のような名前は避けてください。1 週間後の自分も含めて、誰も中身を思い出せません。そしてブランチは 1 目的で小さく保ち、1 日から 3 日で終わる大きさにします。長生きするほど main との差が開き、マージのときの衝突が大きくなります。