ローカルとGitHub——作業場所と保存先の違い

作業場所とGitHubは別の場所

ChatGPTにサイトの修正を頼むと、接続された開発環境の中で、ファイルを開いて編集し、必要な確認をします。ここが作業場所です。あなた自身のパソコンの中の場合もあれば、インターネット越しに使うクラウド上の環境の場合もあります。

GitHubにも対応する保存先がある

一方のGitHubは、リポジトリという単位でファイルや変更履歴を管理し、共有するサービスです。作業場所にもリポジトリのコピーがあり、GitHub上にも対応するリポジトリがあります。片方で変えた内容が、必ずしも瞬時にもう片方へ反映されるわけではありません。

例えば、クラウドの作業環境を借りてコツエイゴの記事を書いたとします。記事の文章がその環境に保存されても、GitHubに送る操作が済んでいなければ、GitHub側にはまだない場合があります。さらに、GitHubへ送った後も、本番サイトへの公開は別の段階です。

クラウドでも「ローカル」と呼ぶ

「ローカル」という言葉は、いまGitを動かしている環境側を意味します。クラウド環境の中でGitを実行しているなら、そのクラウド環境が作業者から見たローカルです。「手元のパソコンにファイルがある」という意味とは限りません。

自分で操作していなくても、ChatGPTに「今回のローカルは、どの環境のどの場所を指す？」と聞けます。環境の名前やフォルダの場所、GitHub上の保存先を区別して説明してもらえば、作業の報告が読みやすくなります。

作業環境は一時的に用意されることもあります。環境の終了後に何が残るかは使うサービスや設定で異なるため、「この環境を閉じた後、未pushの変更は残る？」と聞いて確認しましょう。クラウドという名前だけで、永久に保存されると決めつけないことが大切です。

大切なのは、名前よりも実際の場所を確かめることです。

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

コミットとpushはどう違う？

前の記事で学んだコミットは、選んだ変更をひとまとまりの履歴としてGitに記録する操作でした。通常、その記録はまず作業環境のリポジトリに作られます。コミットしただけで、GitHubにも同じ履歴が届いたとは限りません。

pushは履歴を送る操作

push（プッシュ）は、手元側のコミットをGitHubなどの別のリポジトリに送る操作です。例えば記事の本文を編集し、「記事を追加」というコミットを作った後、作業用のブランチへpushすると、対応するGitHub側のブランチにも履歴が送られます。

ブランチとは、変更の流れを分けて扱うための名前です。詳しい使い方は第7記事で学びます。今は「どの流れに送ったかも確認する」と覚えれば十分です。GitHubの作業ブランチに送ることと、mainに取り込むことも別です。

記録に含めなかった変更は別

また、編集したファイルがすべてコミットに含まれたとは限りません。コミットされていない変更は、そのコミットをpushしても送られません。「変更は残っていない？」「どのブランチにpushした？」と聞くと、保存範囲がはっきりします。

送信に失敗した場合、原因は権限や接続、相手側の更新などさまざまです。何度も操作を繰り返す前に、AIに完了した操作と失敗した操作、現在の状態を分けて確認しましょう。

たとえば、本文と画像の2つを変えたのに本文だけをコミットした場合、pushされるのはそのコミットに含まれた記録です。画像の変更が別の未記録のまま残っていないか、ファイルごとの状態を確認してもらいましょう。

fetchとpullは何を受け取る？

他の人や別の環境がGitHub側を更新したとき、今の作業場所にその情報を取り込む必要があることがあります。そのための操作として、fetch（フェッチ）とpull（プル）が登場します。

fetchは情報を取得する

fetchは、GitHubなどから新しいコミットや参照の情報を取得します。取得した情報は作業環境のGitに記録されますが、通常、いま開いている作業ファイルはfetchだけでは変更されません。「相手側がどこまで進んだかを確認する準備」と考えてみましょう。

pullは取得後に取り込む

pullは、一般にfetchした後、取得した変更を現在のブランチへ取り込む操作です。取り込み方法は設定などにより異なり、マージやリベースが使われます。状況によっては衝突が起きたり、未保存の変更があるため停止したりすることもあります。

操作前に今の状態を確認

ここで重要なのは、fetchとpullは同じ操作ではないことです。fetchは情報を取得し、pullはさらに現在の作業へ取り込もうとします。自動的に安全な結果になると決めつけず、AIに今のブランチや未コミットの変更を確認してもらいましょう。

たとえば別の作業で記事が更新されたかを知りたい場合、「まず取得して差分を確認し、私の作業に影響があるか説明して」と依頼できます。実際に取り込むかどうかは、その後の報告を見て判断できます。

GitHub上の変更と自分の変更が同じ部分に触れていると、取り込みの際にどちらをどう残すか判断が必要になることがあります。これが衝突の一例です。AIに解消を頼む際も、他の人の変更と自分の変更の両方を守るよう伝えます。

作業後はどこまで進んだか確認する

「保存しました」という一文だけでは、作業環境に保存したのか、GitHubまで送ったのか、分からないことがあります。報告を受け取ったら、まず場所を分けて確認してみましょう。

場所・履歴・送信先を聞く

「どの環境で作業した？」「何をコミットした？」「GitHubのどのブランチにpushした？」。この3つを聞けば、作業場所・履歴・送信先が見えてきます。送信がまだなら、未送信とその理由も確認しましょう。

公開は別に確認する

「mainに反映した？」「本番サイトで見られる？」も別の質問です。GitHubにpushされていても、mainや公開サイトに反映されていないことがあります。サイトごとに公開の仕組みは違うため、ChatGPTの報告で実際に行った操作を確かめます。

確認結果にも注目します。「テストに成功した」と「まだテストしていない」は別です。失敗や未確認の項目も含めて教えてもらうと、次に何をすればよいか判断しやすくなります。

全部の用語を覚える必要はありません。場所と段階を分けて聞くことから始めれば大丈夫。次の記事では、実際の報告を例に、変更ファイルやブランチ、検証結果の読み方を練習します。

聞いた結果は「作業環境に記録済み」「GitHubに送信済み」「mainは未反映」「本番は未公開」のように、同じ形式で並べてもらうと比較しやすくなります。分からない項目を推測で埋めず、不明として報告してもらいましょう。