「公開する」という別作業がない
サイトを更新するとき、「作業する」と「世の中に公開する」は、別の作業だと思われがちです。ところがVercelとGitHubを連携させておくと、この2つは1つの動作にまとまります（Vercelというサービス自体についてはそもそもVercelとは何かをどうぞ）。
git pushでリモート（GitHub）に変更を送ると、それをVercelが検知して、自動的にビルド（サイトを作り直す作業）とデプロイ（公開）を行ってくれます。「pushしたら、勝手に公開される」——これがVercelとGitHubを繋ぐ最大のメリットです。
Gitにおけるリモートとローカルの違いで説明した「ローカルの変更をリモートに送る」という行為が、そのまま「世の中に公開する」行為にもなっている、とイメージしてください。
本番とプレビュー、2種類のデプロイ
- メインのブランチ（多くの場合
main）にpushする → 本番環境（実際に公開されているサイト）が更新される - それ以外のブランチにpushする → 本番とは別の、確認用の「プレビュー環境」が作られる
プレビュー環境は、本番に影響を与えずに「これで大丈夫そうか」を確認できる場所です。心配なら、まずプレビューで確認してから、本番用のブランチにpushする、という進め方もできます。
覚えておきたいこと
pushが公開に直結するということは、pushする瞬間は、思っている以上に重みを持つ行為だということでもあります。特にサイトが実際に人の目に触れるようになってからは、「今pushして大丈夫か」を一呼吸置いて考える習慣を持っておくとよいでしょう。
とはいえ、公開してしまってからでも戻せます。 組み立て直しを待たずにひとつ前の状態へ戻す方法は公開したものを、ひとつ前に戻すに書きました。戻せると分かっていると、押す前に固まる時間が短くなります。
手元では動いていたのに本番だけ落ちる、という詰まり方をしたときは手元では動くのに、本番で落ちる——環境変数の置き場所のほうかもしれません。