状態と履歴を確認する（status / log）
いまどのファイルが変更され、何がステージに載っているかは git status で確認します。これは作業中に最もよく使うコマンドで、迷ったらまず status を打つのが鉄則です。これまでのコミットの流れは git log でたどれ、誰がいつ何を記録したかが新しい順に並びます。git log --oneline を使うと1コミット1行に圧縮され、全体像をつかみやすくなります。
Git を使っていると、いつの間にか「いま自分がどこにいるのか」を見失う。それを防ぐ羅針盤が、状態を見る git status と、履歴をたどる git log の2つだ。
Git ではファイルが作業ツリー・ステージング・リポジトリの3つの領域を行き来する。だから「いま何がどの段階にあるのか」が頭の中だけでは追えなくなる。そこで、現在の状態を教えてくれる status と、これまでの記録の流れを見せてくれる log を、こまめに確認しながら作業を進める。
この2つは履歴を書き換えたりファイルを壊したりしない「見るだけ」のコマンドだ。迷ったら何度打っても安全で、むしろ操作の前後に挟むほど事故が減る。
🧭 足元を確かめる git status
git status は、3つの領域がいまどうなっているかをまとめて教えてくれる、最もよく使うコマンドだ。
何か操作して結果に確信が持てないとき、次に何をすべきか分からなくなったとき、まず status を打つ。これが Git を扱ううえでの鉄則だ。
status の出力はいくつかの見出しに分かれる。まだ Git が追跡していない新しいファイルは「Untracked files」、git add 済みで次のコミットに含まれる変更は「Changes to be committed」（git-staging に載った状態）、編集したけれどまだ add していない変更は「Changes not staged for commit」として並ぶ。
何も変更がなければ「nothing to commit, working tree clean」と表示される。これは「手元はきれいで記録すべき変更が一つもない」状態を意味する。
💬 status は次の一手も教えてくれる
status は、状態を見せて終わりではない。次にどう操作すればよいかのヒントも出してくれる。
たとえば編集しただけのファイルがあると「git add でステージに載せる」よう促し、ステージ済みの変更があると「git restore --staged で降ろせる」と案内する。
Git のメッセージは初学者にも分かるよう書かれている。英語でも構えずに読んでみると、次の一手がそのまま書いてあることに気づく。
慣れるまでは、編集したら status、add したら status、commit したら status、というくらい頻繁に挟んで構わない。
📋 短い形式 git status -s
出力が長くなりがちなときは、git status -s（または --short）が便利だ。
-s を付けると1ファイル1行の短い形式になり、行頭の2文字の記号で状態を表す。左側の文字がステージングの状態、右側が作業ツリーの状態を示す。
たとえば ?? は未追跡のファイル、A はステージに追加された新規ファイル、 M（右側のM）は変更したがまだ add していないファイル、を意味する。
ファイル数が多いプロジェクトでは、この短い形式のほうが全体を一覧しやすく、慣れると素早く状況をつかめる。
📜 来し方をたどる git log
足元が分かったら、次は「これまで何をしてきたか」だ。これまでに積み重ねたコミット（git-commit）の流れを見るのが git log である。
実行すると、コミットが新しい順に上から並び、それぞれのハッシュ・作者・日時・コミットメッセージが表示される。ただし既定の表示は1コミットあたりの情報が多く、数が増えると全体像がつかみにくくなる。
そこで日常的によく使うのが git log --oneline だ。これは1つのコミットを「短いハッシュ＋メッセージ」の1行に圧縮して並べるので、履歴の流れをひと目で見渡せる。
たとえば「e4f5g6h Add second line」「a1b2c3d Add readme」のように、上が新しく下が古い順で表示される。この一覧こそが、Git でいう「履歴」の正体だ。
🌿 枝の分岐を地図にする
枝が分かれていると、一覧だけでは「どこで分かれてどこで合流したか」が見えてこない。それを地図のように描く組み合わせがある。
git log --oneline --graph --all と打つと、--graph がブランチの枝分かれと合流を左側にアスキーアートの線で描き、--all がすべてのブランチを対象に含める。
枝（git-head が指す現在位置を含む各ブランチ）が複数あるときに、その分岐と合流を見渡せるので、マージの前後で打つと状況把握に役立つ。
なお、いま自分がどのコミットを基準にしているかは HEAD（git-head）という印が指し示している。log の出力でも、最新のコミットのそばに HEAD が表示される。
🚪 全画面で固まったときの抜け方
git log を実行したら画面が全画面に切り替わり、入力を受け付けなくなることがある。慌てなくていい。
履歴が長い場合、最終行にコロン（:）が出て入力を待ち受ける状態になる。初学者は「固まった」と勘違いしがちだが、これはページャ（less と同じ仕組み）が動いているだけだ。
スペースキーで次のページへ進み、上下キーで1行ずつスクロールできる。読み終えたら q キーを押せば抜けられる。
この操作感は less でファイルを読むときとまったく同じだ。片方を覚えればもう片方にもそのまま通じる。
↔ status と log の使い分け
status と log は、役割を分けて考えると迷わない。
status は「これから何を記録すべきか・今どの段階にいるか」という現在の作業状況を見るために使う。log は「これまで何をしてきたか」という過去の流れをたどるために使う。
たとえば、コミットする前には status で含める内容を確認し、過去のある変更がいつ入ったのかを調べたいときは log --oneline でメッセージを目で追う。バグがいつ混入したかを探すときも、まず log で怪しいコミットの見当をつけるところから始まる。
特定のファイルがどう変わってきたかだけを追いたいときは git log --oneline -- <ファイル名> のようにファイルを指定すると、そのファイルに関係するコミットだけに絞れる。
この2つを息をするように打てるようになると、Git の上での見通しが一気に良くなる。まず status で足元を確かめ、log で来し方を振り返る。この往復が、Git を安心して使うための基本のリズムだ。