GitHubへの保存・mainへの反映・本番公開はどう違う？

変更が届くまでの3つの段階

ChatGPTにサイトの修正を頼むと、作業後に「変更を保存しました」「mainへ反映しました」などの報告を受けることがあります。どれも作業が進んだことを示しますが、同じ意味ではありません。

たとえば、記事の見出しを直したら

コツエイゴの記事の見出しを直す例で考えます。まず変更を作業ブランチに保存し、GitHubに送ります。次に、必要な確認をして、その変更をmainに取り込みます。さらに公開の仕組みを通して、読者が見るサイトへ反映します。

この例では、① GitHubの作業ブランチに保存、② mainに反映、③ 本番サイトに公開、という3つの状態を分けています。「本番サイト」は読者が普段アクセスする実際のサイトです。「本番」という言葉は、練習用ではなく実際に使う環境を表します。

報告には「どこまで」が大切

たとえば「GitHubに保存しました。本番公開はしていません」は矛盾しません。保存先に変更は残っていても、読者が見るサイトにはまだ届いていないことがあります。どこに保存したかも一緒に聞くと、より正確に分かります。

ただし、これは一例です。すべてのサイトで同じ順番や操作が必須なわけではありません。ブランチや公開の設定はサイトごとに違います。作業ブランチに送っただけでも、設定によりプレビュー作成などの自動処理が動くことがあります。

公開とアクセスできる範囲

「公開」という言葉も、誰に見える場所かが重要です。自分たちだけが確認するプレビューと、読者向けの本番サイトは別の場合があります。「どのURLで、誰が見られる状態？」と尋ねると、言葉の行き違いを減らせます。

別の例では、修正内容を確認するためのURLが先に発行されることもあります。そのURLで変更が見えたとしても、いつもの本番URLが更新されたとは限りません。二つのURLが何を示すのか、報告の中で確認してみましょう。

なるほど！ まずは何が起きているか、ひとつずつ確かめればいいんだね。

GitHubへの保存は変更を送ること

記事を作った作業環境には、変更したファイルがあります。第4記事で学んだコミットは、変更をひとまとまりの履歴として記録することでした。どのブランチ上で記録したかも一緒に確かめましょう。

コミットとpushは別

第5記事で扱った push（プッシュ） は、そのコミットを作業環境からGitHubなどのリモートリポジトリへ送る操作です。コミットしただけでは、まだGitHubに送っていない場合があります。逆に、GitHub上で直接変更を記録する方法もあり、作業の場所は一つとは限りません。

報告が「変更をコミットしました」だけなら、「GitHubにも送った？ どのブランチ？」と聞いてみます。コミットの識別子（コミットSHA）を一部提示してもらうと、どの履歴なのかを確認する手掛かりになります。

どのブランチに保存した？

たとえば「作業ブランチ article/example にコミットし、GitHubへpushしました」と報告されたら、その変更は指定されたGitHubのブランチにあります。作業ブランチに送ったことだけでは、mainへ入ったことにはなりません。

もちろん、GitHubへのpush先がmainである場合は、mainの更新にもなります。だから「pushしたか」だけでなく「どこへpushしたか」を確かめる必要があります。直接mainを更新できるか、してよいかはリポジトリのルール次第です。

保存されたことと見られること

リポジトリの公開範囲によっては、GitHub上のファイルを他の人が見られます。ここでいう「本番サイトに公開していない」は、GitHubの内容が誰にも見えないという意味ではありません。リポジトリの公開設定とサイトの公開は分けて考えます。

「保存」という日常の言葉は、ファイルを作業環境に保存したことにも、GitHubへ送ったことにも使われます。曖昧なときは、誰かを責める必要はありません。「作業環境とGitHubのどちらにある？」と聞けば、次に必要な操作が分かります。

mainへの反映は変更を取り込むこと

main は、多くのリポジトリで中心となるブランチの名前です。前の記事で学んだように、作業ブランチを分けて変更を進め、あとでmainに取り込めます。中心となるブランチの名前や使い方は、サイトごとに違う場合もあります。

PRとマージの役割

取り込み方法の一つが、第8記事のプルリクエスト（PR）とマージです。PRは変更を提案・確認する場、マージは変更を取り込む操作です。PRを作っただけでは、mainに入ったことにはなりません。

第9記事で見たコンフリクトがあれば、必要な変更を確認して解決してから進めます。また衝突がなくても、依頼していない別の作業が混ざっていないか確認しましょう。取り込みの前後で何を確認したか、ChatGPTに報告してもらえます。

mainもGitHub上のブランチ

mainも、GitHub上のブランチの一つです。したがって「GitHubに保存」と「mainに反映」は完全に無関係な場所を指す言葉ではありません。前者はGitHub上に変更があること、後者は特定のブランチmainに変更が入ったことを表します。

たとえば「作業ブランチに保存済み、main未反映」なら、変更はGitHub上にあってもmainには入っていません。「mainにマージ済み」なら、取り込み先が本当にmainだったか、最終的な変更も含めて確認します。

「mainに反映済み」と「公開済み」

「mainに反映したら必ず公開済み」とも「必ず未公開」とも言えません。mainの更新をきっかけに自動公開される設定もあれば、別の公開操作が必要な設定もあります。サイトの仕組みと実行結果を確認しましょう。

本番公開は読者のサイトに届けること

本番公開は、変更を読者が利用するサイトへ反映することです。サイトを配信する環境へ変更を届ける処理を「デプロイ」と呼ぶこともあります。どの操作でデプロイが始まるか、設定はサービスやサイトによって異なります。

自動と手動のどちらもある

自動公開の設定では、mainへの反映をきっかけに公開処理が始まることがあります。ただし、処理が始まったことと、最後まで成功したことは別です。途中で失敗すれば、mainが更新されても本番には反映されていない可能性があります。

手動公開の設定なら、mainに取り込んだ後、決められた方法で公開処理を実行する必要があります。自動か手動かにかかわらず、公開先や実行結果を確認し、実際の本番ページでも意図した変更が見えるか確かめます。

コツエイゴの場合

コツエイゴでは、作業ブランチへの保存と、mainへの反映、本番公開を分けて扱っています。公開するときは指定された手順で対象のmainを公開し、公開後にページを確認します。これはコツエイゴの運用例であり、他のサイトにもそのまま当てはまるとは限りません。

たとえば「GitHubの作業ブランチへ保存済み、main未反映、本番未公開」という報告なら、3段階のうち最初の状態が分かります。「main反映済み、公開処理は成功、実ページは未確認」なら、公開処理と読者の画面確認を分けて読めます。

報告を3つに分けて読む

公開後に変化が見えない場合は、すぐに同じ操作を繰り返す前に、対象のサイト・ページ、公開処理の結果、どの変更を公開したかを確認します。確認できたこと、失敗したこと、まだ調べていないことを分けてもらいましょう。

次の記事では、公開の前後に使うプレビューやテスト、デプロイの確認を詳しく見ます。まずは「保存先」「main」「読者の画面」を別々に尋ねられれば大丈夫です。

依頼する時点で「今回はGitHubの作業ブランチへの保存まで」「mainまで反映し、本番公開は行わない」のように終了地点を伝えると、目的が共有しやすくなります。ただし実際に何が起きたかは、自動処理の有無も含めて結果で確かめましょう。