AIに「GitHubが必要です」と言われたら
AIにアプリやWebサイトを作ってもらっていると、「Gitを初期化しますか」「GitHubにリポジトリを作りますか」と聞かれることがあります。初めて見ると、コードを書くために別のサービスへ登録しなければならないように感じるかもしれません。
GitとGitHubは、作ったものの記録と共有を支える道具です。ただし、それぞれ役割が違います。
- Gitは、ファイルの変更履歴を手元のパソコンに残す仕組み
- GitHubは、そのGitの履歴をインターネット上で共有するサービス
この違いが分かれば、AIが何をしようとしているのか、どこまで任せてよいのかを判断しやすくなります。この記事では、ログイン画面の文言を直す小さな作業を例に、GitとGitHubを使う一連の流れを追います。
Gitは「変更の履歴」を残す仕組み
開発では、同じファイルを何度も書き換えます。変更がうまくいくとは限りません。昨日まで動いていた画面が崩れたり、試した機能を取りやめたりすることもあります。
ファイルを毎回「完成版」「完成版2」「本当の完成版」のように複製しても、どれが現在のものか、何を変えた版なのかはすぐに分からなくなります。Gitは、そうした変更を意味のある区切りごとに記録します。
たとえば、次のような履歴を残せます。
- ログイン画面を作った
- ボタンの文言を「送信」から「ログイン」に変えた
- 入力欄の表示崩れを直した
あとから履歴を見れば、何をどの順番で変えたかをたどれます。変更前後の差を比べたり、問題が始まった場所を調べたりすることもできます。
Gitで管理しているプロジェクトのひとまとまりをリポジトリ（repository）と呼びます。普段見ているプロジェクトのファイルに、Gitが管理する変更履歴を加えた単位だと考えるとよいでしょう。
Gitを使い始めただけでは、ファイルがインターネットへ送られることはありません。Gitは自分のパソコンだけでも使えます。
GitHubは、Gitの履歴を共有する場所
GitHubは、Gitのリポジトリをインターネット上に置けるサービスです。手元の履歴をGitHubへ送ると、ほかの人や別のパソコンから同じ履歴を取得できます。連携したサービスで、テストや公開の処理を動かすこともできます。
左側が自分のパソコンにあるGitのリポジトリ、右側がGitHubです。右向きの矢印は手元の履歴を送る操作、左向きの矢印はGitHubにある履歴を手元へ取り込む操作を表しています。
GitHubで共有すると、ファイルを置くだけでなく、次のことができます。
- 変更案を見せて、コメントやレビューを受ける
- 複数人が同じプロジェクトで作業する
- 変更のたびにテストを自動で実行する
- 誰が、何を、なぜ変えたのかを残す
- GitHubの履歴からWebサイトやアプリを公開する
最後の公開は、プロジェクトにその仕組みが設定されている場合だけ起こります。GitHubへ送ることと、利用者へ公開することは別です。
始め方は二通りある
Gitを使い始める場面は、大きく二つに分かれます。
新しく作るプロジェクト
自分のパソコンにある普通のフォルダを、Gitで管理し始めます。この操作をinit（初期化）と呼びます。初期化すると、そのフォルダの変更履歴をGitで記録できるようになります。
AIが「Gitリポジトリを初期化します」と言ったら、プロジェクトをGitで管理できる状態にしようとしています。この時点では、まだGitHubへ送っていません。
GitHubにすでにあるプロジェクト
GitHub上のリポジトリを、履歴ごと自分のパソコンへ複製します。この操作をclone（クローン）と呼びます。
ファイルだけをダウンロードするのとは違い、cloneでは、それまでの変更履歴とGitHubとの接続情報も一緒に取得します。次回以降は、GitHub側で増えた変更をpullして手元へ取り込みます。
一つの変更が記録になるまで
ここからは、ログインボタンの文言を「送信」から「ログイン」へ直す場面を考えます。
1. ファイルを編集して保存する
まず、エディタやAIがファイルを書き換えます。この段階では、ファイルを保存しただけです。Gitは変更があったことを見つけられますが、その変更は履歴として確定していません。
この作業中のファイルがある場所をワーキングツリー（working tree）と呼びます。
2. 何が変わったか確かめる
Gitは、変更されたファイルの一覧や、変更前後の差を表示できます。現在の状態を見る操作がstatus、具体的な差を見る操作がdiffです。
AIに作業を頼んだときも、いきなり記録させるのではなく、「変更したファイルとdiffを説明して」と頼めます。これで、頼んでいないファイルまで変わっていないかを確認できます。
3. 次の記録に入れる変更を選ぶ
確認した変更のうち、次の記録に含めるものを選びます。この操作がstage（ステージ）です。選ばれた変更はいったんステージングエリアに置かれます。
この選ぶ段階があるため、ログインボタンの修正中にメモファイルも書き換えたとしても、ボタンの修正だけを一つの記録にまとめられます。
4. コミットして履歴に残す
ステージした変更を、理由が分かる短い説明とともに履歴へ残します。この記録がcommit（コミット）です。
今回なら、「ログインボタンの文言を修正」のような説明を付けます。コミットした時点で、変更は手元のGit履歴に入りました。ただし、まだGitHubには届いていません。
図のWORK、STAGE、COMMITまでは、主に自分のパソコンで進みます。この三段階を分けて考えると、「保存しただけなのか」「次の記録に選んだのか」「履歴として確定したのか」が分かります。
なぜブランチを作るのか
一人で小さな修正をするだけなら、一本の履歴にコミットを重ねることもできます。しかし、AIに機能追加を頼んだり、複数人で作業したりすると、完成前の変更を安定した履歴へ直接入れたくない場面が増えます。
そこで使うのがブランチ（branch）です。ブランチは、コミットの流れの先端に付ける名前です。プロジェクトのフォルダを丸ごと複製するものではありません。
図では、基準となるmainの途中から、作業用のfeatureが分かれています。ログイン画面の修正をfeature側へ記録している間は、mainを変更せずに作業できます。確認が終わったら、二つの流れをmerge（マージ）して合流させます。
ブランチを切り替える操作がswitchです。AIに「手元のmainがリモートの最新状態と一致するか確認し、最新のmainから今回専用のブランチを作って切り替えて」と頼むと、作業の置き場所を分けられます。
GitHubで共有し、変更を取り込む
手元でコミットできたら、次はGitHubを使う段階です。
1. pushでGitHubへ送る
手元で増えたコミットをGitHubへ送る操作がpush（プッシュ）です。pushすると、ほかの人やGitHub上の自動テストから変更を見られるようになります。
非公開リポジトリなら、通常は権限を持つ人だけが見られます。それでも、パスワード、APIキー、.envの中身などをコミットしてはいけません。GitHubへ送る前に、秘密情報が含まれていないか確認します。
2. pull requestで変更を提案する
作業用ブランチの変更を基準ブランチへ取り込んでもらう提案がpull requestです。PRやプルリクとも呼ばれます。
PRには、変更の説明、実際の差分、レビューの会話、自動テストの結果が集まります。Gitのコマンドではなく、GitHubなどの共有サービスが提供する機能です。
3. mergeで基準の履歴へ取り込む
内容を確認し、問題がなければPRをmergeします。これで、作業用ブランチの変更が基準ブランチへ入ります。
4. pullで手元も新しくする
GitHub上でmergeしても、手元のファイルまで自動で更新されるわけではありません。GitHub側の新しい履歴を手元へ取り込む操作がpull（プル）です。
これで一周です。次の作業では、また最新の基準ブランチから新しい作業用ブランチを作ります。
commit、push、PR、merge、公開は別の段階
名前が続くと混乱しやすいので、何がどこまで進むのかを並べます。
- commit：変更を手元のGit履歴に記録する
- push：その履歴をGitHubへ送る
- PR：送った変更を取り込むよう提案する
- merge：提案された変更を基準ブランチへ取り込む
- 公開・deploy：Webサイトやアプリとして利用者へ届ける
AIが「完了しました」と言ったときは、どの段階まで終わったのかを確認してください。「コミットしたがpushしていない」と「本番へ公開した」では、外部への影響が大きく違います。
最初は、AIにここまで伝えられればよい
自分でコマンドを打てなくても、作業の場所と段階が分かれば、AIに具体的に頼めます。
作業を始めるとき
現在のGitの状態とブランチを確認してください。私の未コミットの変更は消さず、手元の基準ブランチがリモートの最新状態と一致するか確認してから、今回専用の作業用ブランチを作ってください。
変更を記録するとき
変更したファイルとdiffを説明してください。今回の目的に関係する変更だけをステージし、コミットする前に内容を確認させてください。
GitHubへ共有するとき
秘密情報が含まれていないことを確認してからpushし、基準ブランチ向けのPRを作ってください。mergeや公開はまだ行わないでください。
大切なのは、Gitのコマンドをすべて覚えることではありません。変更が「作業中」「次の記録に選択済み」「手元に記録済み」「GitHubへ共有済み」「基準へ取り込み済み」のどこにあるかを区別することです。
AI駆動開発でエージェントにGit操作を頼むときに知っておきたい言葉は、「AI駆動開発で困らないためのGit・GitHub用語」で整理しています。