git add後の変更はコミットされる？消したデバッグログが残る理由と確認方法

2026年9月18日

レビューへ出したコードに、削除したはずのデバッグログが残っていた。エディタでは消えているし、手元のテストも通っている。なぜ古い内容がコミットされたのか。

git addの後に編集した内容は、自動ではステージへ反映されません。この記事では、通常のgit commitを使う場合に、何が記録されるかを二つの差分で確かめます。commit -aやファイルを直接指定するコミットは、今回の例には混ぜません。

addは「このファイルを予約する」ではなく、「今の内容を次のコミット用に置く」操作。
add後の修正も入れるなら、もう一度addします。その前後でgit diff --cachedを読み、実際に提出する内容を確認してください。

デバッグログを消しても、ステージには残っている

例えば、処理へ一時的なログを足してaddし、その後にログを削除したとします。

ここで通常のgit commitをすると、ステージの「ログあり」が記録されます。エディタに見える最新状態ではありません。git-add公式資料にも、実行時点の内容を登録し、その後の変更には再度addが必要と説明されています。

git status --short
git diff
git diff --cached

コマンド	比較する場所	今回の例で見たいもの
git diff	ステージと作業ツリー	add後にデバッグログを消した差分
git diff --cached	HEADとステージ	次のコミットへ入る差分。ログが残っていないか

git diffだけ読んで「ログは消えている」と安心しないでください。その差分は、まだステージに入っていない変更を示しています。--stagedは--cachedと同じ用途で使えます。git-diff公式資料

同じファイルがstagedとunstagedの両方に出るのは異常ではありません。競合していない今回の状態なら、短いstatusはMMになります。左がステージ、右が作業ツリーの変更です。

デバッグログを消した状態を含めるなら、対象ファイルを指定してやり直します。

git add UserService.java
git diff --cached -- UserService.java
git status --short

差分に必要な修正があり、不要なログがないことを確認してからコミットします。関係ないファイルもある状態で、確認せずgit add .を使う必要はありません。

一方、add後の編集を別コミットに残すなら、再addしなくて構いません。ただし、ステージの内容だけで成立していることを確かめます。

普段のビルドやテストは、作業ツリーのコードを使います。例えばメソッド呼び出しをaddした後、足りなかったimportを追加してテストを通しても、そのimportが未ステージならコミットには入りません。

初心者のうちは、同じ変更に必要なコード・import・テストをまとめてステージし、未ステージ差分が残る理由を説明できる状態にすると確認しやすくなります。

部分的に分ける場合は、コミットした状態そのものをCIや別の検証用作業場所で確認します。手元の差分を捨てて検証しようとしないでください。

初期コミットが存在するリポジトリなら、次の操作で編集を残したままステージを解除できます。

git restore --staged UserService.java

--stagedを省略したgit restore UserService.javaは、作業中の変更へ作用します。同じ操作ではありません。この記事の目的は編集の削除ではなく、次のコミットから外すことです。git-restore公式資料

未追跡ファイルは通常のdiffだけでは見落とすため、statusも必要です。コミット後はgit show HEADで実際の記録を見ます。これで「エディタにあるもの」と「提出したもの」を区別できます。

『改訂2版わかばちゃんと学ぶ Git使い方入門』は、ステージやチーム作業を図と画面で整理したい人向けの候補です。出版社の紹介で対象範囲を確認できます。掲載画面と現在のツールの画面には違いがあり得ますが、まず状態の区別を学ぶ目的で選べます。

※Amazonのリンクにはアフィリエイトを含みます。