この記事の結論（先に3つだけ）
結論から書きます。Git（ギット）は、ファイルの変更を記録して、何人もで同じものを作るための仕組みです。私はAIに、学校の「文集」にたとえて説明してもらいました。ブランチは下書き、main は清書、マージは清書に写すこと。確認の3問には全問正解し、しかも3問目は、出題したAIの想定より私の答えのほうが正確でした。
- ブランチ＝下書き、main＝清書、マージ＝清書に写すこと。 この3つで、AIたちが何をしているかが読めるようになった
- 「承認がいる変更」と「いらない変更」は、変えるものの種類で分かれている。 チャットによって聞いてきたりこなかったりするのは、気まぐれではなかった
- 清書に入っても、各パソコンには勝手に届かない。 取りに行って初めて届く。これが過去の事故の原因そのものだった
50代・非エンジニアです。プログラミングはできません。
前回の Claude Code のフックの話 でも、「main」「ブランチ」「git push」といった言葉が何度も出てきました。
AIたちは毎日「枝を切りました」「main に取り込みました」「マージしてよいですか」と報告してきます。その言葉の意味を、私が一度きちんと教わった記録があります。
今回は、それをきちんと覚えた日の話です。2026年9月8日に説明の資料を作ってもらい、翌9日に確認の3問を受けました。
Git とは：ファイルの変更を記録して、みんなで1つのものを作る仕組み
Git は、ファイルをいつ・誰が・どう変えたかを記録しておく仕組みです※1。 何人もが同じファイルを同時に触っても、ぶつからないように作られています。
私の保管庫（AIたちが共有するメモの置き場所）も、Git で管理する形です。保管庫の本体は GitHub という、インターネット上の置き場所にあります。Mac や Windows、クラウドのAIたちは、そこから写しを取ってきて作業し、終わったら送り返します。
AIが説明に使ったのは、クラスみんなで作る「文集」のたとえでした。
| Git の言葉 | 文集でいうと | 私の保管庫でいうと |
|---|---|---|
| リポジトリ | 文集そのもの（1冊） | 保管庫 |
| main | 清書。みんなが読む本番 | Obsidian で見えているもの |
| ブランチ | 下書き用のコピー。自分の机の上 | claude/○○ という名前のもの |
| コミット | セーブ。「ここまで書いた」の印 | 記録1件ぶんの保存 |
| プッシュ | 机の下書きを先生の棚に置く | GitHub へ送る |
| プルリクエスト | 「清書に入れていいですか」と手を挙げる | 私に承認を求める |
| マージ | 先生が「いいよ」と言って清書に写す | 私が「マージして」と言う |
| コンフリクト | 2人が同じ行を違う内容で書いた | まれに起きる |
表の中で、私の作業にいちばん関係が深いのは「コミット」と「プッシュ」でした。AIたちが記録を1件書くと、それがコミット（セーブ）になります。そのセーブを GitHub に送るのがプッシュです。保管庫の決まりには、Windows のAIは記録を書いたら必ず自分でプッシュする、と書いてあります。送らないと、ほかのAIからはその記録が見えないからです。
branch は英語で「枝」、main は「幹」です。 木を思い浮かべると、名前の理由が分かります。幹から枝が出て、また幹に戻る。それがブランチとマージです。
Git のブランチとマージを、文集の流れで追う
AIは、文集ができあがるまでの流れを5段階の図にしてくれました。 私が覚えたのは、この順番です。
- 本番の清書がある（main）
- 清書をまるごとコピーして、自分の机に持っていく（ブランチを切る）
- 下書きに書く。書いたらセーブする（コミット）
- 「清書に入れていいですか」と手を挙げる（プルリクエスト）
- 「いいよ」で清書に写る（マージ）
資料には、これを線で描いた図も入っていました。●が清書、○が下書きのセーブです。
main ●━━●━━●━━━━━━━━━━◆ ← 清書に写った（マージ）
┃ ↗
┗━━○━━○━━○ ← 下書き（ブランチ）でセーブを重ねる
幹（main）から枝（ブランチ）が出て、セーブ（コミット）を重ね、また幹に戻る。図にすると、名前のとおりの形をしています。
「プルリクエスト」という名前にも理由がありました。下書きを持っている人が「入れてください」と頼み、本番を持っている側が引き取る（pull する）。だから pull（引く）＋ request（お願い）です※2。日本語なら「取り込み依頼」だそうです。
なぜ、わざわざコピーを作るのか
コピーを作る理由は2つありました。
- 本番を壊さないため。 下書きで失敗しても、清書は無傷です
- 何人も同時に書いているため。 こちらが本命でした
9月8日の時点で、私の GitHub には下書き用のコピーが20本以上ありました。事業ごとのチャットが、それぞれ自分のコピーを持って作業しているのです。
AIの説明はこうでした。1冊のノートに10人が同時に書き込むのは無理。だから全員が自分のコピーを持つ。
毎朝AIから届く「枝を○本取り込みました」という報告は、このたとえで読むとこうなります。各チャットが机の上で書いた下書きを、毎朝まとめて清書に写しているのです。
Git でプルリクを使うときと使わないとき：チャットで答えが違った理由（独自）
私がずっと不思議だったのは、「マージしてよいですか」と聞いてくるチャットと、聞いてこないチャットがあることでした。 気まぐれだと思っていましたが、違いました。
保管庫の決まりでは、変えるものによってやり方が2つに分かれています。
| 何を変えるか | やり方 | 私の手 |
|---|---|---|
| 日々のメモ・記録・資料 | いきなり清書に書く（main へ直接） | 要らない |
| ルールや仕組み（CLAUDE.md・手順書・見張り役） | 下書き → 手を挙げる → 承認 | 「マージして」の一言 |
AIのたとえは、こうでした。日報は自分でノートに書いてよい。就業規則を変えるときは社長のハンコが要る。
「マージして」で私が承認しているもの
では、私が「マージして」と言うと、何が起きるのか。AIは流れをこう書いていました。
- 私が「マージして」と言う
- 清書（main）が書き換わる
- ほかの全部のチャットが、それを取りに来る
- Mac や Windows のターミナルにも届く
- Obsidian にも届く
つまり、ルールの改訂を承認することは、全部のAIの行動を一斉に変えることです。
保管庫には、過去の事故の記録も残っていました。2026年8月22日、確認を怠って、誤った規則を全部のセッションへ複製してしまったことがあったのです。だから承認が要る。逆に、日々のメモにハンコは要らない。だから2つに分けてある、という説明でした。
確認の3問：全問正解、しかも3問目は私の答えのほうが正確だった
説明を受けた翌日、AIは確認の3問を出してきました。 結果は3問とも正解でした。
| 問題 | 私の答え | 判定 |
|---|---|---|
| ブランチは文集でいうと何か | 下書き | 正解 |
| なぜプルリクを聞くチャットと聞かないチャットがあるか | ルール変更のときだけ「マージして」と言っている | 正解 |
| マージしたあと、Windows のターミナルに届くか | 届かない。ただ、ターミナルが Git を見に行ったときに確認できる | 正解（出題者の想定より正確） |
2問目は、AIの記録に「自分から言い当てた」と書いてありました。
3問目は、AIの問題文のほうが雑だった
3問目の、出題したAIが用意していた答えは「届く」でした。 ところが私は「届かない。ただ、見に行ったときに確認できる」と答えました。
AIは保管庫の決まりを読み直して、こう認めています。Windows 側には自動の同期が無い。取りに行くまで、手元は古いまま。私の答えのほうが正しかった。
記録には、AI自身の言葉でこう書いてありました。
出題時の想定解は「○ 届く」だった。これは雑だった。
AIは、自分の採点表の「判定」の欄にも「出題者の想定より正確」と書き添えています。間違いを指摘されたのではなく、採点する側が自分で問題文の穴に気づいて、記録に残した形です。
なぜ食い違ったのか。AIの説明では、「届く」という言葉に2つの意味が混ざっていました。
- GitHub の清書（main）に入る
- 各パソコンの手元のフォルダが新しくなる
問題文が、この2つを分けていなかったのです。
「勝手には届かない」が、過去の事故の原因だった
この3問目は、ただの言葉の問題ではありませんでした。AIは、保管庫の実害と直結していると書いています。
- 保管庫の決まりには「作業を始める前に、最新の状態を取り直す」とある
- 2026年8月11日に、メモ置き場の取りこぼしが実際に起きている
- メモを片付ける手順書には「取り直す前に一覧を見ないこと」とある
「勝手には届かない。取りに行って初めて届く」。これが、こうした事故の原因そのものでした。
保管庫の決まりを見ると、パソコンごとに届き方が違います。
| どこで動くAIか | 保管庫の持ち方 | 新しい清書の受け取り方 |
|---|---|---|
| クラウドのAI | GitHub から写しを作る | 作業を始めるたびに取りに行く |
| Mac のターミナル | Mac の中にある本体そのもの | Obsidian のプラグインが10分ごとに自動で送る（閉じていたら自分で送る） |
| Windows のターミナル | 写し | 自動の同期は無い。 取りに行くまで古いまま。書いたら必ず自分で送る |
つまり、清書（main）が新しくなっても、Windows の手元は、誰かが取りに行くまで昔のままです。3問目の「届かない。ただ、見に行ったときに確認できる」は、この表のいちばん下の行をそのまま言い当てていました。
AIたちが作業の最初に git fetch（最新を取りに行く）というコマンドを打つ決まりになっているのも、このためです。
Git の基本を「覚えた」と登録すると、何が変わるか
3問に正解したあと、AIは保管庫の「覚えたこと」の一覧に1行を足しました。 この一覧に載ったものは、AIが説明を省いてよい、という決まりです。
登録された中身は次のとおりです。
- ブランチ＝下書き、main＝清書、マージ＝清書に写すこと
git pushは、AIが使う別の道具（MCP）とは別物であること- 保管庫では「記録・資料は main へ直接、ルール変更だけ承認が要る」の2種類に分かれていること
- main に入っても、ターミナル側は取りに行くまで古いままであること
私の保管庫のルールでは、AIは私に「中学生に説明するつもりで書く」ことになっています。ただし、私が「覚えた」と言ったものは、意味の説明を省いてよいことになっています。
これで、毎朝の報告はその分だけ短く書いてよいことになりました。
おわりに：Git の基本でわかったこと
今回の区切りで分かったことは、次の4件です。
- ブランチは下書き、main は清書、マージは清書に写すこと。 これだけで、AIの報告の大半が読めるようになった
- 承認が要るかどうかは、変えるものの種類で決まる。 日報はそのまま、就業規則はハンコ
- 清書に入っても、各パソコンには勝手に届かない。 取りに行って初めて届く
- 言葉が2つの意味を持つと、問題文も答えも食い違う。 「届く」はその例だった
かかった費用は0円です。資料づくりと確認の3問で、2日にまたがりました。
1つ、まだ確かめていないことがあります。Mac 側の「届き方」は、今回の3問では扱いませんでした。 Mac は Obsidian のプラグインが10分ごとに自動で同期するので、Windows とは事情が違います。Obsidian を閉じているあいだは届かないのかどうか、次に Mac の話が出たときに確かめる予定です。
出典
- ※1 Git – ブランチとは（Pro Git 日本語版）
- ※2 プル リクエストについて（GitHub Docs）
