モダンなWeb開発の現場では、GitHubやVercelなどのツールを連携させて、開発から本番リリースまでの一連のプロセスを自動化する「CI/CDパイプライン」が標準化されています。
一見複雑に見えるこの仕組みですが、「本番環境を絶対に壊さない」という目的から紐解くと、非常にロジカルな構造をしています。今回は、開発の現場で実際に行われているリリースの流れと、その安全性を支える仕組みを解説します。
1. 大前提：リリースの安全を守る「2つのブランチ（環境）」
まず、すべてのベースとなるGitのブランチ構造を整理します。開発の現場では、「ブランチ」と呼ばれるコードの並行世界を作ることで、それぞれの「環境」を構築・隔離しています。
| ブランチ名 | 対応する環境と役割 |
|---|---|
| mainブランチ | 本番環境：実際のユーザーがアクセスしている本番のコード。常にバグのない状態を保つ必要がある。 |
| featureブランチ | 作業環境：開発者が自分のPC（ローカル）で、新機能の開発やバグ修正を行うための隔離されたコード空間。 |
本番環境を直接書き換えることは絶対にしないため、「開発者がmainブランチで直接作業してPushすることはしない」というのが鉄則です。
開発者は必ず feature ブランチ（作業環境）でコードを書き、完成したら「mainブランチ（本番環境）に合体させてください」という申請をGitHub上で出します。この申請のことを「プルリク（Pull Request）」と呼びます。
2. 開発から本番リリースまでの5つのステップ
プルリクが出されてから本番にリリースされるまでのプロセスは、ツールによる自動処理と、人間による手動検証を組み合わせて以下の順番で実行されます。
- 【開発者】プルリクの作成： 開発者が
featureブランチでの作業を終え、GitHubにコードをPushしてプルリクを出す。 - 【Vercel】検証用環境の自動構築： プルリクが出たことをVercelが検知し、そのプルリク専用の「使い捨ての検証用環境（URL）」を自動で立ち上げる。
- 【GitHub Actions】自動テストの実行： 検証用環境が完成したのを合図に、GitHub ActionsがPlaywrightなどの自動テストを起動・実行し、その結果（合格 ✅ または不合格 ❌）をプルリク画面に表示する。
- 【QAエンジニア】手動テスト： 自動テストが合格したのを確認し、人間のQAエンジニアがVercelの検証用URLを開いて、実際の挙動や使い心地を手動で確認する。
- 【開発リーダー】マージ（本番反映）： すべてのテストをクリアしたことを確認し、開発リーダーがGitHub上の「マージボタン」を押して
mainブランチにコードを合体させる。その後、Vercelが本番サイトを自動更新する。
3. コンフリクト解消の正しい仕組みと、テストが走るタイミング
チーム開発では、他の人の変更と自分の変更が衝突する「コンフリクト」が発生することがあります。
よくある勘違いとして、「プルリクを受けた側の開発リーダーが、GitHubの画面上で適切にコンフリクトを直してマージしてくれる」と思われがちですが、それは間違いです。正しくは、「プルリクを出した側の開発者が、自分の手元でコンフリクトを完全に解消してからでないと、開発リーダーはマージボタンを押せない」という仕組みになっています。
では、コンフリクトが発生して開発者が修正対応を行った場合、自動テストはいつ走るのでしょうか？
コンフリクト修正時、テストが走るタイムライン
結論から言うと、開発者がコードを修正してPushするたびに、自動テストは何度でも走り直します。
- 衝突発生： プルリクを出した時点、あるいはレビューを待っている間に、先に他のメンバーが作った別の
featureブランチがmainブランチにマージされることでコンフリクトが発生し、画面上のマージボタンがロックされる。 - 手元での修正： プルリクを出した側の開発者が、自分のPCで最新の
mainブランチをPullし、衝突したコードを安全に直す。 - 再Push（テストの再実行）： 開発者が直したコードを再度GitHubにPushすると、VercelとGitHub Actionsがそれぞれ自らPushを検知する。Vercelは検証環境を最新に上書きし、GitHub Actionsは2回目の自動テスト（Playwright）を自動的に実行する。
このように、コンフリクト解消後のコードに対して再度テストが走るため、修正によって別の場所が壊れていないかを確実に保証できます。
4. プルリクはコミットではなくブランチ自体に紐づいている
コンフリクトを修正して追加でPushした際、GitHub上の古いプルリク画面は自動的に最新状態へと上書き更新されます。そのため、人間がプルリクを一回取り消したり、新しく出し直したりする必要はありません。
毎回プルリクを出し直す必要がない理由は、プルリクやマージが、特定の時点のコードの塊（コミット）ではなく、「feature ブランチという器そのものに紐づいているから」です。
GitHubのプルリクはブランチそのものを監視しているため、開発者が手元で直して追加でPushすると、プルリク画面の中身も連動して自動的に最新の状態へと切り替わります。人間は無駄な手順を踏むことなく、1つのプルリク画面の中で最後まで作業を完結できます。
5. なぜコンフリクトがあってもプルリクを出せるのか？
そもそも、コンフリクト（衝突）が起きた状態であっても、GitHubはプルリクを出すこと自体は制限しません。なぜなら、プルリクには「コードを見ながらメンバーに相談する部屋」という役割もあるからです。
「ここが衝突しちゃったんだけど、どう直すのが正解？」といったコミュニケーションを開発者同士が画面上で行うために、あえてオープンにできるようになっています。相談の場はいつでも作れますが、安全が証明（コンフリクト解消・テスト合格）されるまでは、本番へ合体させるボタンはロックされるという合理的な設計になっています。
まとめ
GitHubやVercelの設計思想は、徹底して「自由度と安全性のバランス」がとられています。開発者間の相談やコードの修正（Push）はいつでも自由に行えますが、本番環境を壊すリスクがある操作（マージ）に対しては、テストの合格を条件にシステムが厳重なガードを敷いています。このロジカルな仕組みがあるからこそ、現代の開発チームはスピードを落とさずに安全なリリースを維持できているのです。