ステージングとコミット
Gitでは変更をいきなり記録せず、まず「ステージング（インデックス）」という準備エリアに載せてから記録します。git add で記録したい変更を選んでステージに載せ、git commit でその内容を1つの履歴として確定します。コミットには必ずメッセージを付け、「何を・なぜ変えたか」を短く残すのが基本です。この二段階のおかげで、関係する変更だけをまとめて記録できます。
Git の操作で最初に越えるべき山が、「変更をいきなり記録するのではなく、いったん準備エリアに載せてから記録する」という二段構えの考え方です。普通のソフトの「保存」は1回の操作ですが、Git では編集した内容をまず git add で準備エリアに載せ、それから git commit で履歴に確定する、という2ステップを踏みます。一見まわりくどく感じますが、この仕組みがあるおかげで「今編集した5か所のうち、関係のある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 は、まだステージに載せていない編集が、どの行をどう変えたかを行単位で見せてくれます。先頭に + が付いた行が追加された行、- が付いた行が削除された行です。たとえば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回のコミットに混ぜず、別々のコミットに分ける——この習慣が、後々の調べやすさを大きく左右します。