Git と GitHub でつなぐべき理由

01 / 19

AI エージェントは、一度にいくつものファイルを書き換えることがあります。記録が無いと、どこが変わったか・どう戻すかが分かりません。

前の状態を残していなければ、比べる相手も、戻る先もありません。この章では、そのための道具 Git と GitHub が、なぜ AI との作業に要るのかを見ます。

会話では：「AI がいろいろ書き換えて、元に戻せなくなった」——これを防ぐのが、この章の話です。

02 / 19

Git は、ファイルの変化を記録していく道具です。Git に記録を取らせているフォルダー（ファイルと記録のひとまとまり）を「リポジトリ」と呼びます。

記録があると、前の状態に戻す・変化を比べる・いつ誰が変えたかを調べる、ができます。Git は無料で使えるソフトウェアです。

会話では：「このフォルダー、Git で管理してる？」「リポジトリを作っておいて」のように使います。

03 / 19

コミットは、その時点のファイルの状態を、ひとことの説明を付けて記録に残すことです。記録は時間の順に積み重なります。

Git の公式の本は、コミットを「その瞬間のファイルの写真を撮る」ことにたとえています。付ける説明は「コミットメッセージ」と呼びます。

会話では：「ここまでをコミットしておいて」「コミットメッセージは日本語で」のように頼みます。

04 / 19

AI に頼む前に、いまの状態をコミットしておきます。AI の変更がうまくいかなくても、ここへ戻れます。

OpenAI の Codex の説明も、作業の前と後に Git で記録を取り、変更を戻せるようにしておくことを勧めています。

会話では：「AI に触らせる前にコミットしておいて」「作業前の状態はコミット済み？」のように使います。

05 / 19

AI が作業すると、ファイルが書き換わります。この時点では、まだ記録していない変更です。

Git は、最後のコミットと比べて、どのファイルのどこが変わったかを見せてくれます。それが次の「差分」です。

会話では：「まだコミットしていない変更が残っている」のように言います。

06 / 19

差分は、最後のコミットから何が変わったかを、行ごとに見せたものです。+ は増えた行、- は消えた行です。

書き換えた行は、- の古い行と + の新しい行の組で出ます。頼んだ変更のほかに、頼んでいないところまで変わっていないかも、差分を見れば気づけます。

会話では：「差分を見せて」「diff を確かめてからコミットする」のように使います。

07 / 19

差分を見て問題がなければ、AI の変更をコミットします。良い状態が、また1つ記録に足されます。

コミットも AI に頼めます。Claude Code の説明は、作業の最後に「分かりやすいメッセージでコミットして」と頼む流れを紹介しています。

会話では：「よさそうなので、分かりやすいメッセージでコミットして」のように頼みます。

08 / 19

反対に、だめだったときは AI の変更を捨てて、最後のコミットの状態に戻せます。記録があるから、気軽に試せます。

記録してあったファイルが、最後のコミットの中身に戻ります。Git では git restore などのコマンドがこの役目をし、AI に「その変更を取り消して」と頼むこともできます。

会話では：「さっきのコミットまで戻して」「この変更は捨てていい」のように使います。

09 / 19

ブランチ（枝）を分けると、元の線（main）をそのままにして、別の線の上で AI に作業させられます。

うまくいかなければ、その枝を使わずに捨てるだけで済みます。そのあいだ、main は一度も変わっていません。

会話では：「ブランチを切ってから任せる」「新しい枝で試して」のように使います。「切る」は枝を作ることです。

10 / 19

枝の上の作業がうまくいったら、main に取り込みます。これを「マージ」と呼びます。

枝はいくつでも作れるので、やり方を別々の枝で試して、良かったものだけを取り込むこともできます。

会話では：「main にマージして」「この枝はマージしないで捨てる」のように使います。

11 / 19

GitHub は、Git のリポジトリをインターネットの上に置いておけるサービスです。手元の記録を GitHub へ送ることを「プッシュ」と呼びます。

こまめにプッシュしておけば、手元のパソコンに何かあっても、記録は GitHub に残ります。

会話では：「コミットしたらプッシュしておいて」「GitHub に上げておいて」のように使います。

12 / 19

Pull Request（PR）は、「この枝の変更を main に取り込んでください」という提案です。差分を見ながら話し合えます。

PR には、説明・差分・コメントがまとまります。取り込む前に、人の目（や別の AI）で確かめるための場所です。

会話では：「PR を作らせて、差分を見てからマージ」「PR にコメントしておいた」のように使います。

13 / 19

指摘したところは、直しを同じ枝にコミットしてプッシュすれば、PR に加わります。確かめ終わったら、マージします。

Claude Code の説明も、AI が作った PR は出す前に見直し、気になる点を AI に挙げさせることを勧めています。

会話では：「レビューのコメントに対応して」「確かめたのでマージして」のように頼みます。

14 / 19

Issue は、GitHub にやることや不具合を書いておく場所です。先に Issue に書いておけば、その番号を伝えて AI に頼めます。

PR の説明に「Closes #12」のように書くと、main へマージしたとき、その Issue が自動で閉じます。番号は説明のための例です。

会話では：「Issue に書いてから頼む」「Issue #12 を読んで対応して」のように使います。

15 / 19

AI エージェントは、Git のコマンドや gh（GitHub をコマンドで操作する道具）を自分で動かして、コミットから PR づくりまでこなせます。

Claude Code は「create a pr」のように頼むと PR を作り、その裏では gh pr create が動きます。公式の説明は、GitHub を使うなら gh を入れておくよう勧めています。

会話では：「gh は入ってる？」「変更をコミットして PR を作って」のように頼みます。

16 / 19

GitHub にリポジトリがあれば、別のパソコンからも、クラウドで動く AI からも、同じ記録の続きから作業できます。

Claude Code をクラウドで動かすと、GitHub からリポジトリを持ってきて（クローン）作業し、枝をプッシュします。手元だけのコミットは、先にプッシュしておくよう説明されています。

会話では：「クラウドで動かすなら、先にプッシュしておいて」のように使います。

17 / 19

OpenAI の Codex や Google の Antigravity CLI にも、Git や GitHub とつながるしくみがあります。AI の変更を差分で見直したり、GitHub の中から AI を呼んだりできます。

図は各社の公式の説明で確かめた例です。以前からある Gemini CLI もありますが、Google は最新の Gemini モデルでのコーディングには Antigravity CLI を勧めています（2026年10月時点）。

会話では：「PR に @codex review と書いてレビューさせる」「Issue に @claude と書いて頼む」のような使い方もあります。

18 / 19

第10章のチェックポイントも作業を巻き戻せますが、それはその AI ツールの中だけの手早いしくみです。ずっと残す記録は Git が受け持ちます。

Claude Code の説明は、チェックポイントは Git の代わりではないと書いています。コマンドだけで書き換えたファイルは、チェックポイントでは戻りません。

会話では：「チェックポイントで戻す？ Git で戻す？」——その場の手直しはチェックポイント、残す記録は Git、と使い分けます。

19 / 19

つなげると、AI との作業は「Issue → 枝を切る → 任せる → 差分を見る → コミット・PR → 確かめてマージ」の流れになります。

Git と GitHub の操作の手順は、同じ作者の GitHubをはじめよう（外部サイト・新しいタブで開きます） で、1つずつ手を動かして覚えられます。

会話では：「Issue を立てて、ブランチを切って、PR まで作って」——この一言が通じれば、この章の言葉はそろっています。