変更履歴とコミット——サイトの修正はどう記録される？

まずは変更前と変更後を比べる

サイトの見出しを「AIノート」から「AIの学習ノート」に直したとします。修正前と修正後を比べて、どの文字が追加・削除されたかを示すものが「差分」です。英語ではdiffと呼ばれることもあります。

差分を見ると、お願いした文章が変わっているかだけでなく、意図しない場所も変わっていないかを確かめられます。AIに「変更した内容を初心者にもわかるように要約して」と頼めば、コードをすべて読めなくても確認の入口を作れます。

一つの変更に複数のファイル

画面上は見出しだけが変わったように見えても、サイトの仕組みによっては、文章と表示に関わる複数のファイルを修正する場合があります。複数ファイルが変わったことだけで誤りとは決めつけず、それぞれの役割を聞きましょう。

一方、依頼していない内容まで変更されているように見えたら、「この変更は今回の目的に必要ですか？」と尋ねられます。変更の理由を聞いたうえで、何を残すか判断します。人が理解できる形で説明を受けることも確認の一部です。

差分がない場合もある

変更しようとした内容が最初から同じだったり、編集後に元へ戻したりすると、差分がない場合があります。AIに「差分なし」と言われたときは、何を調べてそう判断したのか、意図した状態が実際に存在するかを確認しましょう。

GitHubや開発環境には、差分を表示する方法があります。画面には追加と削除が色で示されることもありますが、色だけに頼らず、説明や前後の文をあわせて見てください。画面の具体的な見え方は、使うツールや設定によって異なります。

差分の説明は、変更した箇所だけを短く示すことも、関連する文脈を含めて詳しく示すこともできます。何のための変更なのか判断しづらければ、前後の文章とともに説明してもらいましょう。

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

コミットは変更をまとめた記録

Gitでは、記録する変更を選び、ひとまとまりにして残せます。この一つの記録を「コミット」と呼びます。見出しの修正に関係する変更をまとめ、「AIページの見出しを修正」のような説明を付けるイメージです。

コミットにつける説明は「コミットメッセージ」と呼ばれます。あとから履歴を見たときに、何のための変更だったかを探す助けになります。説明だけですべての内容がわかるわけではないので、必要に応じて実際の差分も確認します。

編集しただけではコミットされない

ファイルの編集とコミットは別の操作です。変更は存在していても、記録する対象に選ばれていなかったり、まだコミットされていなかったりする場合があります。AIの「変更しました」と「コミットしました」は区別して読みましょう。

逆に、同じコミットに複数のファイルが含まれることもあります。画面の文章と関連するスタイルを一緒に変更した場合などです。コミットの単位は作業に応じて決められますが、あとで内容を確認しやすいまとまりになっているかが大切です。

一緒に入れる内容に気をつける

自分が頼んだ作業とは別の未保存の変更がある場合、それを無関係にまとめないよう注意が必要です。AIには「今回の依頼に関係する変更だけ確認して」と頼めます。別の作業を上書きしたり消したりせず、まず現在の状態を調べてもらいましょう。

「記録した」という言葉は便利ですが、作業環境でコミットしたこととGitHubへ送信したことも同じではありません。どこまで済んだかを確認すれば、後から別の環境で続けたいときにも役立ちます。

コミットはプロジェクト全体の履歴の中に位置づく記録です。メッセージがあると探しやすくなりますが、記録の中身を理解するには、変更されたファイルや差分もあわせて確認することが大切です。

履歴から変更をたどる

コミットを重ねると、プロジェクトには変更の履歴が残ります。履歴には、各コミットの説明や作成者、日時などを確認できる場所があります。表示される項目や順番は、利用する画面によって異なります。

それぞれのコミットには、識別するための「コミットSHA」と呼ばれる文字列があります。たとえば、0123456789abcdef0123456789abcdef01234567 のような、数字と a〜f の英字からなる40文字です。これは説明用の架空の例で、実際の記録を指すものではありません。画面や報告では、先頭の 0123456 のように短く表示されることもあります。GitHubで一般的な形式の例ですが、環境によって識別子の形式や短縮する長さは異なります。暗記する必要はなく、特定の記録を探す目印と考えましょう。

どの変更を見ているか

AIに「さっきの変更を見せて」と頼むときは、記事名や作業内容、わかればコミットの識別子を添えると、対象を特定しやすくなります。変更が複数ある場合は「この記録に含まれるファイルと変更内容を教えて」と聞けます。

履歴を見られることは、すべての操作を自分で行う必要があるという意味ではありません。まずは、AIが示した記録を確認し、何を変えたか、想定した作業が含まれているかを説明してもらいましょう。必要に応じてGitHubの画面でも確認できます。

過去の状態に戻す前に

過去の記録は、問題が起きたときに原因を調べる手がかりになります。ただし「前に戻す」方法には複数あり、今の変更や他の作業に影響することがあります。実行前に、戻したい対象と影響範囲をAIに説明してもらいましょう。

履歴に残ったからといって、本番サイトがその状態になっているとは限りません。作業ブランチ上の記録なのか、mainに反映されているのか、公開まで済んでいるのかは別に確認します。前の記事で学んだ区別がここでも役立ちます。

同じ作業について複数のコミットがある場合もあります。どれが最終的な修正なのかわからないときは、AIに時系列で整理してもらい、今の状態につながる記録を確認してみましょう。

ChatGPTのコミット報告を読み解く

「AIページの見出しを修正し、変更をコミットしました。GitHubの作業ブランチに送信しました。本番公開はしていません」は、一連の作業についての一つの報告例です。3つの文はそれぞれ、記録・GitHubへの送信・本番公開の状態を伝えています。

コミットしても公開されていないことがある

この報告は矛盾していません。コミットしたけれど、まだ本番公開していないことは普通にあります。たとえば、記事を書き直して変更履歴を記録し、GitHubの作業ブランチに送り、内容の確認を待っている状態です。読者が見るサイトは、公開する別の作業を行うまで変わらないことがあります。

コミットはどこに記録される？

「コミットしました」は、通常、作業中のブランチに変更の記録を作ったという意味です。ただし、それが作業ブランチなのかmainなのかは、どのブランチで作業したかによります。また、作業環境でのコミットと、GitHubへのpushは別です。「ブランチに保存」という表現だけでは、作業環境だけなのかGitHubまで送ったのか曖昧なので、両方を確認しましょう。

mainへの反映と本番公開は別

「mainに反映した」は、作業ブランチの記録をmainに取り込むなどして、main側に変更が入った状態です。コミットしただけでは通常そこまで分かりません。「本番に公開した」は、読者が見るサイトへ変更を反映した状態です。GitHubやmainへの反映をきっかけに自動公開される設定もあるため、実際の状態はサイトの仕組みと報告で確認します。

一方、「変更しましたが、コミットはまだです」と言われたら、編集は行われたもののGitの記録はまだありません。途中の状態として保存先を確認し、続きに何をするかをAIと相談しましょう。結果が不明な場合は、再実行する前に現在の状態を調べます。

確認する質問

「何を変更した？」「コミットにはどのファイルが入っている？」「どのブランチに保存した？」のように質問を分けると、報告の内容を確認しやすくなります。対象外の変更がある場合は、その扱いを勝手に決めず、まず状態を説明してもらいます。

コミットメッセージが自分にわかりにくい場合は、日常の言葉で言い換えてもらいましょう。たとえば「変更したファイル名より、画面で何が変わるかを先に説明して」と頼めます。詳しい情報と、理解するための短い要約は両立できます。

公開したかどうかも別に聞く

GitHubに送られた記録があっても、それが本番サイトに反映されたかは別の確認です。公開を依頼していなければ、「本番公開していない」と報告してもらうことで、確認中の原稿と読者に見えるページを混同しにくくなります。

ここまでで、差分は「何が変わったか」、コミットは「変更のひとまとまりの記録」、履歴は「記録をたどるもの」と整理できます。次の記事では、作業環境とGitHubの間でデータをやり取りするときの言葉を学びます。

報告を読むとき、知らない単語をまとめて覚えようとしなくても大丈夫です。まずは「何を変えたか」「記録したか」「どこにあるか」の三つを押さえ、必要な言葉を一つずつ確認していきましょう。もし報告と画面が食い違って見えたら、どちらかを推測で正しいと決めず、対象のブランチと確認した時点を伝えて、AIに読み取りで再確認を頼むと原因を探しやすくなります。まずは一つずつ確認しましょう。