Claude Code が打つコマンドの読み方

Claude Code に作業を任せていると、許可画面に Git のコマンドが次々に出てきます。1つずつ見ると細かいのですが、並べてみると打つ順番には型があります。変える前に見て、変えたらまた見る、という型です。この回では、作業を始める前からコミット、push までを1本の流れとして追い、それぞれのコマンドが何を確かめているのかと、出力のどの行を見ればよいかを読み解きます。コマンドそのものの説明は、第1部・第2部の各回に任せます。

画面の見方
  • 上のターミナルは、Windows のノート PC で実際に打ったときと同じ出力です(Git は英語で答えます)
  • 下の中で起きていることには、グラフが2つ並びます。上が GitHub 側、下が手元です。丸がコミット、黒い札がブランチ、ピンクの札が HEAD、点線の札 origin/main は手元に貼ってある GitHub の写し(2-1 の追跡ブランチ)です
  • 3節と4節では、ファイルの中身を追うために3つの場所(作業ツリー・ステージ・HEAD のコミット)も出します
  • 4つの区間は1本の話で、前の区間の終わりが次の区間の始まりです
  • 右の説明をスクロールして読み進めると、左のターミナルでコマンドが1つずつ打たれます。→ キーでも1つずつ進みます(← で1つ戻ります。スマホでは「次へ」ボタン)。最後まで進んでから → を押すと次の区間へ移ります。黄色く光っているのが、そのコマンドで変わった場所です

1. 見る・変える・見る — 打つ順番の型

Claude Code の過去の全セッションログから、実際に打った Git のコマンドを数えました。延べ約14,000回のうち、上位は git status(3,052回)・git diff(2,628回)・git add(1,976回)・git log(1,885回)・git commit(1,490回)・git show(619回)・git fetch(555回)・git push(310回)の順です。

このうち見るだけの status・diff・log・show の4つで約8,200回、全体の約6割です。Claude Code が打つ Git のコマンドの大半は、何も変えずに様子を見るためのものです。

見るコマンドは、変えるコマンドの前後に挟まって出てきます。1つの作業を段階に分けると、次のように並びます。

段階変える前に見る変える変えたあとに見る
作業を始める前(2節)git statusgit fetch -qgit status・git branch --show-current
変更の確認とステージ(3節)git diff --stat・git diffgit add ファイルgit diff --cached --stat・--cached --name-only
コミット(4節)git commit -m "…"git log --oneline -3・git show --stat
送る(5節)git status・git log --oneline -3git push -qgit status・git log --oneline -1・git branch -r --contains

許可画面にコマンドが出たら、「いまどの段階か」「見るほうか、変えるほうか」を当てはめてみてください。変えるほうなら、直前に見た出力が判断の材料になります。

2. 作業を始める前 — status を2回打つ理由

作業の前には、git status・git fetch -q(fetch 555回のうち405回がこの形)・git status・git branch --show-current の順によく打ちます。確かめているのは、書きかけが無いか、GitHub より遅れていないか、どのブランチに積むのかの3つです。

status を2回打つのは、2-3 fetch と pullで見たとおり、status は GitHub に見に行かず、手元の写し origin/main と比べて答えるからです。Windows のノート PC と Mac の2台で同じリポジトリを使っていると、この差が「Mac で直したのに、こちらでは直っていない」の正体になります。

作業を始める前 — status・fetch -q・status・branch --show-current

  1. Windows のノート PC で、Claude Code が作業を始めます。最初の git status は、書きかけが無いか(working tree clean)を見ています。2行目の up to date は、手元の写し origin/main と比べた答えです。

    $ git status
    On branch main
    Your branch is up to date with 'origin/main'.
    
    nothing to commit, working tree clean
  2. 昨夜 Mac で push した「パンを追加」が GitHub 側にあります。git fetch -q は何も表示しませんが、手元の origin/main の付箋はそこまで進みました。

    $ git fetch -q
  3. 同じ git status を、fetch のあとにもう一度打ちます。2行目が behind 'origin/main' by 1 commit に変わりました。status を2回打つのは、fetch の前と後で答えが違いうるからです。

    $ git status
    On branch main
    Your branch is behind 'origin/main' by 1 commit, and can be fast-forwarded.
      (use "git pull" to update your local branch)
    
    nothing to commit, working tree clean
  4. いま乗っているブランチの名前だけが1行で出ます。これから積むコミットが main に入ることを確かめています。

    $ git branch --show-current
    main
  5. 早送りで済むと分かったので、main を origin/main まで進めます。Updating a1c4f20..c43e6a8 と Fast-forward が出れば、追いつきました。

    $ git pull --ff-only
    Updating a1c4f20..c43e6a8
    Fast-forward
     todo.txt | 1 +
     1 file changed, 1 insertion(+)
  6. 括弧の中に HEAD -> main と origin/main が並んでいます。GitHub と同じところから作業を始められる、という確認です。

    $ git log --oneline -1
    c43e6a8 (HEAD -> main, origin/main, origin/HEAD) パンを追加

git branch --show-current(1-3)は1行だけなので読みやすく、何も出なければ detached HEAD です。fetch のあとの status が have diverged なら、作業の前に2本をつなぎます(3-1 merge・3-2 rebase)。

3. 変更を確かめて、ステージに載せる

ファイルを書き換えたあとは、広く見てから、狭く見る順番で diff を打ちます。git diff --stat(719回)でどのファイルが何行変わったかを見て、気になれば git diff で中身を見ます。add したあとは --cached --stat(341回)や --cached --name-only(243回)で、ステージの側を見ます。比べている場所の違いは 1-1 3つの場所とコミットの表のとおりです。

この区間では、頼んだのは todo.txt だけなのに、自分で書きかけていた notes.txt の変更も残っている、という確認が役に立つ場面を見ます。

変更を確かめてステージに載せる — diff --stat・diff・diff --cached

  1. Claude Code に「買い物メモにバターを足して」と頼み、todo.txt が書き換わりました。notes.txt には、自分で書きかけていた1行があります。status の赤い欄に、2つとも modified で並びます。

    $ git status
    On branch main
    Your branch is up to date with 'origin/main'.
    
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git restore <file>..." to discard changes in working directory)
    	modified:   notes.txt
    	modified:   todo.txt
    
    no changes added to commit (use "git add" and/or "git commit -a")
  2. --stat は、ファイルごとに何行変わったかの一覧です。見るのは ファイル名の列 で、頼んだ覚えのないファイルが混ざっていないかを確かめます。ここでは notes.txt が混ざっています。

    $ git diff --stat
     notes.txt | 1 +
     todo.txt  | 1 +
     2 files changed, 2 insertions(+)
  3. 中身を見るときは --stat を外します。+ で始まる行が足された行です。notes.txt の +火曜は特売 は、今回の作業とは関係のない書きかけだと分かります。

    $ git diff
    diff --git a/notes.txt b/notes.txt
    --- a/notes.txt
    +++ b/notes.txt
    +火曜は特売
    diff --git a/todo.txt b/todo.txt
    --- a/todo.txt
    +++ b/todo.txt
    +バターを買う
  4. そこで、todo.txt だけをステージに写します。git add . ではなくファイル名を書くのは、こういう書きかけを拾わないためです。

    $ git add todo.txt
  5. --cached は ステージと HEAD のコミット の差、つまり次のコミットに入るものです。todo.txt の1ファイル・1行だけになりました。

    $ git diff --cached --stat
     todo.txt | 1 +
     1 file changed, 1 insertion(+)
  6. --name-only は、ファイル名だけを並べます。この一覧が、そのままコミットに入るファイル です。

    $ git diff --cached --name-only
    todo.txt
  7. 緑の欄(Changes to be committed)に todo.txt、赤の欄に notes.txt が分かれました。赤の欄のファイルは、このままコミットしても入りません。

    $ git status
    On branch main
    Your branch is up to date with 'origin/main'.
    
    Changes to be committed:
      (use "git restore --staged <file>..." to unstage)
    	modified:   todo.txt
    
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git restore <file>..." to discard changes in working directory)
    	modified:   notes.txt
    

--stat で見るのは行数よりもファイル名の列です。頼んだ作業と関係のないファイルが並んでいたら、そこで止まって中身を確かめます。許可画面で git add . を見かけたら、この一覧を思い出してください。. は一覧に出たファイルを全部拾います。

4. コミットして読み返す

コミットのあと、Claude Code は git log --oneline -3(401回)と git show --stat(217回)で自分の作業を読み返します。log は「歴史の先頭に入ったか」、show は「何が入ったか」の確認で、1行の読み方は 1-2 歴史を読むで見ました。

コミットして読み返す — commit・log --oneline -3・show --stat

  1. 前の区間の続きです。todo.txt にバターの1行、notes.txt に自分の書きかけの1行があります。

  2. 前の区間と同じく、todo.txt だけをステージに写します。

    $ git add todo.txt
  3. [main af62c16] は「main に af62c16 のコミットを積んだ」、次の行はそのコミットが変えた量です。ここが 2 files changed なら、何かが余計に入っています。

    $ git commit -m "バターを追加"
    [main af62c16] バターを追加
     1 file changed, 1 insertion(+)
  4. 1行目 だけを見ます。いま作ったメッセージに (HEAD -> main) が付いていれば、コミットは歴史の先頭に入りました。2行目の (origin/main, origin/HEAD) は、GitHub の写しがまだ1つ前にあるという印です。

    $ git log --oneline -3
    af62c16 (HEAD -> main) バターを追加
    c43e6a8 (origin/main, origin/HEAD) パンを追加
    a1c4f20 店のメモを追加
  5. いま作ったコミットに入ったファイルの一覧です。todo.txt だけで、notes.txt は入っていません。

    $ git show --stat
    commit af62c16 (HEAD -> main)
    
        バターを追加
    
     todo.txt | 1 +
     1 file changed, 1 insertion(+)
  6. 2行目は ahead of 'origin/main' by 1 commit(まだ送っていないコミットが1つ)です。notes.txt は赤の欄に残っていて、書きかけはそのまま無事です。

    $ git status
    On branch main
    Your branch is ahead of 'origin/main' by 1 commit.
      (use "git push" to publish your local commits)
    
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git restore <file>..." to discard changes in working directory)
    	modified:   notes.txt
    
    no changes added to commit (use "git add" and/or "git commit -a")

見る場所は3か所です。commit の出力の2行目の 1 file changed、log の1行目の (HEAD -> main)、show の合計の行の上に並ぶファイル一覧。3つとも「意図したファイルだけが入った」と言っていれば、読み終わりです。

許可画面では、commit が次のような形で出てくることもあります。

git add todo.txt && git commit -m "$(cat <<'EOF'
バターを追加

Co-Authored-By: …
EOF
)"

&& は「前が成功したら後ろも打つ」で、判断はつながったコマンドを1つずつ読んで行います。<<'EOF' から EOF までの行(Co-Authored-By: の行も含む)は、そのまま -m のメッセージとして渡しているだけです。

5. 送って、届いたかを確かめる

Claude Code の push は git push -q の形が多く、うまくいくと何も表示しません(2-2 git push)。そのため前後に、別のコマンドで送るものと届いたかを確かめます。

送って、届いたかを確かめる — push -q・status・log --oneline -1

  1. 前の区間の続きです。2行目の ahead of 'origin/main' by 1 commit が、まだ送っていないコミットの数です。

    $ git status
    On branch main
    Your branch is ahead of 'origin/main' by 1 commit.
      (use "git push" to publish your local commits)
    
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git restore <file>..." to discard changes in working directory)
    	modified:   notes.txt
    
    no changes added to commit (use "git add" and/or "git commit -a")
  2. 送られるのは、(origin/main, origin/HEAD) の付いた行より 上の行 のコミットです。ここでは「バターを追加」の1つだけです。

    $ git log --oneline -3
    af62c16 (HEAD -> main) バターを追加
    c43e6a8 (origin/main, origin/HEAD) パンを追加
    a1c4f20 店のメモを追加
  3. --contains HEAD は、いまのコミットを含む追跡ブランチだけを出します。何も出ないのは、「バターを追加」がまだどの origin/ の写しにも入っていない、つまりまだ送っていないからです。

    $ git branch -r --contains HEAD
  4. -q を付けた push は、うまくいくと何も表示しません。上の GitHub 側の main と、手元の origin/main が「バターを追加」へ進みました。

    $ git push -q
  5. 出力の無い push が届いたかを、2行目で確かめます。ahead が消えて up to date with 'origin/main' に戻りました。

    $ git status
    On branch main
    Your branch is up to date with 'origin/main'.
    
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git restore <file>..." to discard changes in working directory)
    	modified:   notes.txt
    
    no changes added to commit (use "git add" and/or "git commit -a")
  6. HEAD -> main と origin/main が同じ行に並びました。手元の main と GitHub の写しが、同じコミットにあるという意味です。

    $ git log --oneline -1
    af62c16 (HEAD -> main, origin/main, origin/HEAD) バターを追加
  7. push のあとは origin/main が出ます。「バターを追加」が GitHub の main の写しに入った、つまり送ってあるという答えです。

    $ git branch -r --contains HEAD
      origin/HEAD -> origin/main
      origin/main
  8. push が送るのはコミットだけです。notes.txt の書きかけは送られず、作業ツリーに残っています。

    $ cat notes.txt
    駅前のスーパー
    火曜は特売

もう1つ、push の前後で打つのが git branch -r --contains コミットID です。追跡ブランチのうち、そのコミットを含むものを一覧します。上の区間でも push の前と後で打ちました。読み方をまとめるとこうなります。別の PC から push された分まで確かめるには、先に git fetch が要ります。

いつ打ったか出力読み方
push の前(何も出ない)どの追跡ブランチにも含まれていない。まだ送っていない
push のあとorigin/HEAD -> origin/main
origin/main
GitHub の main の写しに含まれている。送ってある

6. 出力のどこを見るか — 早見表

確かめたいことは、たいてい出力の1か所に出ています。

コマンド見る場所読み方
git status2行目up to date・ahead(未送信がある)・behind(遅れている)・have diverged(枝分かれ)
git fetch -q / git push -q何も出ないのが成功結果は次の git status の2行目で見る
git branch --show-current1行いま乗っているブランチ。空なら detached HEAD
git diff --statファイル名の列頼んだ覚えのないファイルが無いか
git diff --cached --name-only全部そのまま次のコミットに入るファイル
git log --oneline -31行目と括弧HEAD -> main の行から origin/main の行の手前までが、まだ送っていないコミット

このうち status の2行目、log の括弧、branch -r --contains は、どれも手元の写しとの比較です。2台で作業しているなら、これらを信じる前に fetch が済んでいるかを見てください。

7. Claude Code の許可画面で見かけたら

この回のコマンドは、ほとんどが「見るだけ」です。変えるコマンドも、何も消しません。

コマンド何が起きるか消えうるもの
git status / git diff(各オプション)/ git log / git show / git branch --show-current / git branch -r --contains見るだけなし
git fetch -q手元の写し(origin/main など)だけを動かすなし
git pull --ff-only早送りで済むときだけ main を進める。済まなければ何も変えずに止まるなし(作業ツリーのファイルは新しい中身になる)
git add ファイル作業ツリーの中身をステージに写す。手元だけなし(git restore --staged で外せる)
git commit -m "…"新しいコミットを足す。手元だけなし(push 前なら 1-5 の git reset --soft HEAD~1 で取り消せる)
git push -qコミットを GitHub に送り、GitHub 側の main を進める注意 消えるものは無いが、GitHub が変わり、ほかの人や別の PC から見える

「注意」は push だけです。手元だけで完結するものは後から取り消せるが、GitHub に出たものは出たという事実が残る、というのが分かれ目です。push を許可する前に、直前の git log --oneline -3 で、送ってよいコミットだけが並んでいるかを見てください。

まとめ

  • Claude Code が打つ Git のコマンドは、status・diff・log・show の見るだけのものが全体の約6割(約14,000回のうち約8,200回)
  • 変えるコマンド(add・commit・push など)の前後に、見るコマンドが挟まる。作業の前は status → fetch -q → status → branch --show-current。status を2回打つのは、fetch の前と後で答えが違いうるから
  • git diff --stat はファイル名の列を見る。--cached --name-only の一覧が、そのままコミットに入るファイル
  • git push -q は成功すると何も出ない。届いたかは status の2行目・log の括弧・branch -r --contains で見る。どれも手元の写しとの比較
  • この回のコマンドで「注意」は push だけ。add と commit は手元だけで、取り消せる

次の回では、この回の外側のコマンドまで広げて、許可画面に出る Git のコマンドを「見るだけ・注意・危険」の3段に分けた判定表を作ります。git reset --hard・git checkout -- ファイル・git clean -fd・git branch -D・git push --force で何が消え、何なら取り戻せるかを、1コマンドずつ確かめます。