状態と履歴を確認する（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 は単に状態を見せるだけでなく、次にどう操作すればよいかのヒントも出してくれます。たとえば編集しただけのファイルがあると「git add でステージに載せる」よう促し、ステージ済みの変更があると「git restore --staged で降ろせる」と案内します。Git のメッセージは初学者にも分かるよう書かれているので、英語でも構えずに読んでみると、次の一手がそのまま書いてあることに気づきます。慣れるまでは、編集したら status、add したら status、commit したら status、というくらい頻繁に挟んで構いません。
出力が長くなりがちなときは 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 でいう「履歴」の正体です。
log にはさらに見やすくする組み合わせがあります。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 --oneline でメッセージを目で追います。バグがいつ混入したかを探すときも、まず log で怪しいコミットの見当をつけるところから始まります。特定のファイルがどう変わってきたかだけを追いたいときは git log --oneline -- <ファイル名> のようにファイルを指定すると、そのファイルに関係するコミットだけに絞れます。この2つを息をするように打てるようになると、Git の上での見通しが一気に良くなります。まず status で足元を確かめ、log で来し方を振り返る——この往復が、Git を安心して使うための基本のリズムです。