コミット前の余分な空白を見つける：git diff --checkで分かること・分からないこと

コードの修正に、行末の空白が紛れ込んだ。Gitのdiff --checkは、差分に含まれる空白の問題などを確認する手段だよ。

この記事は、一時的な練習リポジトリで試す。自動でソースを整形したり、本番のファイルを削除したりしない。空白の確認と、プログラムの動作確認を分けて進めよう。

何を調べるか

git diff --checkは、変更に空白の問題や競合マーカーなどが含まれないか確認し、問題があれば0以外の終了状態を返す。どの空白を問題とするかは、core.whitespaceなどの設定にも関係する。

構文、型、仕様の正しさを調べるテストではない。結果が問題なしでも、コードが動くと保証するものではないよ。

一時リポジトリで行末の空白を作る

空の作業場所で次を実行する。利用者情報は、この練習先だけの設定。

mkdir whitespace-practice
cd whitespace-practice
git init -q
git config user.name Practice
git config user.email practice@example.com
printf 'base\n' > note.txt
git add note.txt
git commit -qm base
printf 'changed \n' > note.txt
git diff --check

changedの後ろには、改行の前に空白が一つある。この例ではtrailing whitespaceという案内と、該当する場所を確認できる。編集部では、この差分で0以外となり、空白を除いた内容では0となることを検証した。

ステージ前と後を分ける

git addしたあとに、最初のコマンドだけで確認を終えないようにしよう。どの差分を見ているかを、通常のdiffやstatusとも照合する。

指摘を機械的に全部消さない

空白に意味がある言語や文書もある。Markdownの改行表現、テスト用の文字列など、意図して含めた内容かを読む。チームのルールがあるなら、その設定や整形ツールも合わせて確認しよう。

終了コードを確認する場合は、別のコマンドで上書きする前に記録する。エラーの表示を隠して、失敗を成功として扱わないことも大切だよ。

比較する場所は追加前・追加後・コミットの違い、状態の読み方は終了コードへ。

参照した公式資料

• Git公式リポジトリ：git-diff

確認日：2026年10月25日。