ステージングとコミット
Gitでは変更をいきなり記録せず、まず「ステージング（インデックス）」という準備エリアに載せてから記録します。git add で記録したい変更を選んでステージに載せ、git commit でその内容を1つの履歴として確定します。コミットには必ずメッセージを付け、「何を・なぜ変えたか」を短く残すのが基本です。この二段階のおかげで、関係する変更だけをまとめて記録できます。
Git では、変更をいきなり記録しない。いったん準備エリアに載せてから記録する、という二段構えになっている。
普通のソフトの「保存」は1回の操作だ。だが Git では、編集した内容をまず git add で準備エリアに載せ、それから git commit で履歴に確定する、という2ステップを踏む。
一見まわりくどい。それでも二段構えにするのは、「今編集した5か所のうち、関係のある3か所だけをひとまとめにして記録する」といった、意味のある単位での記録ができるからだ。
まずはファイルが置かれる3つの場所を頭に入れると、すべてがすっきりつながる。
🗂 ファイルが行き来する3つの場所
Git ではファイルが3つの領域を行き来する。
1つ目は作業ツリー。いま自分がエディタで実際に編集しているフォルダそのもの、つまり「手元」だ。
2つ目がステージング（git-staging）。インデックスとも呼ばれる中間の置き場で、次の記録に含めたい変更を、ここに一時的に載せておく。
3つ目がリポジトリ。確定した記録の並びが保管される場所だ。
流れは一方向だ。作業ツリーで編集したものを git add でステージングへ載せ、ステージングに載ったものを git commit でリポジトリへ刻む。この「作業ツリー → ステージング → リポジトリ」という流れが、Git 操作の背骨になる。
➕ 載せる側 git add
記録したい変更をステージングに載せるのが、git add だ。
git add readme.txt のようにファイル名を指定すると、そのファイルの変更だけがステージに載る。変更したファイルが多く、まとめて載せたいときは git add . と末尾にドットを付ければ、カレントディレクトリ以下の変更を一括でステージできる。
add がうまくいったかは git status で確かめる。まだ追跡されていない新しいファイルは status で「Untracked files」として表示され、add するとそのファイルが「Changes to be committed」（コミット予定）の欄へ移る。この欄に並んだものが、次のコミットに含まれる内容だ。
ここで一つ釘を刺しておく。add はあくまで「載せる」操作で、この時点ではまだ履歴には何も残っていない。
✅ 確定する側 git commit
ステージに載せた内容を、1つの記録（git-commit）として履歴に確定するのが git commit だ。
コミットには必ずメッセージを添える。git commit -m 'Add readme' のように -m の後ろに「何をしたか」を短く書く。
成功すると「[main (root-commit) a1b2c3d] Add readme」のような行が表示される。先頭の main は今いるブランチ名、(root-commit) は「いちばん最初のコミット」であることを示し、a1b2c3d はそのコミットを識別するハッシュの先頭部分だ。
ハッシュは記録ごとに割り振られる固有の番号のようなもので、環境ごとに値は異なる。2回目以降のコミットでは (root-commit) の表示は出ず、ハッシュとメッセージだけが並ぶ。これで1つの記録が履歴に刻まれた。
🖐 一連の流れを手で動かす
言葉で追うより、一連の流れを通して手を動かすほうが腑に落ちる。
echo 'hello git' > readme.txt でファイルを作り、git status で「Untracked files」に readme.txt が出ることを確認する。次に git add readme.txt で載せ、git status で「Changes to be committed」に移ったことを見て、git commit -m 'Add readme' で確定する。
さらに echo 'second line' >> readme.txt と追記したら、また git add readme.txt と git commit -m 'Add second line' を繰り返す。
この「編集 → add → commit」のサイクルこそが、Git の日常そのものだ。
🔎 コミット前に git diff で見直す
コミットを押す前に、自分は本当に意図したものだけを変えたのか、と不安になることがある。それを最終確認したいときに git diff が役立つ。
git diff は、まだステージに載せていない編集が、どの行をどう変えたかを行単位で見せてくれる。先頭に + が付いた行が追加された行、- が付いた行が削除された行だ。たとえば1行を書き足しただけなら、その行が + 付きで1行だけ表示される。
注意したいのは、git diff が見せるのは「未ステージの変更」だという点だ。すでに git add 済みの変更を確認したいときは git diff --staged を使う。
コミットの直前に git diff で目を通す習慣をつけると、意図しない変更が紛れ込むのを防げる。
⚠ つまずきどころと、後で困らない書き方
最も多いつまずきは、git commit に -m を付け忘れることだ。
-m を省くと、メッセージを書くためのエディタ（多くの環境では vi）が突然開き、操作が分からず固まってしまう。慣れないうちは必ず -m 'メッセージ' を付けると安全だ。万一 vi が開いてしまったら :q! と打って Enter で中止できる。
もう一つよくある誤解が、ファイルを編集しただけでコミットすれば記録されると思い込むことだ。編集後に git add でステージへ載せ直さないと、その変更はコミットに含まれない。「編集したら add も忘れずに」を口癖にしておこう。
💌 メッセージには何を書くか
コミットメッセージは「未来の自分への手紙」だ。
1行目はおおむね50字以内で、「何をしたか」を簡潔に書く。'Fix login bug'（ログインの不具合を直す）や 'Add user search'（ユーザー検索を足す）のように、英語なら動詞の原形で始めるのが Git の慣習だ。
実務では、1つのコミットには意味的にまとまった1つの変更だけを入れると、後から履歴を読んだときに流れが追いやすくなる。だからこそ、関係する変更だけを選んでステージに載せられる add の存在が効いてくる。
バグ修正と機能追加を1回のコミットに混ぜず、別々のコミットに分ける。この習慣が、後々の調べやすさを大きく左右する。