git diff가 비어 있는데 변경이 남을 때: 작업 트리·인덱스·HEAD 비교

git add 뒤 일반 git diff가 비어 있다면 변경이 사라졌다고 판단하지 말고 git diff --cached를 확인하세요. 기본 diff는 작업 트리와 인덱스를, --cached는 인덱스와 HEAD를 비교합니다. 먼저 상태와 비교 범위를 읽고 되돌리기 명령은 사용하지 않는 것이 안전합니다.

원인: diff가 비교하는 두 상태를 놓친다

같은 파일도 작업 트리, 스테이징 영역인 인덱스, 마지막 커밋인 HEAD에 서로 다른 내용이 있을 수 있습니다. git add는 이후 커밋할 내용을 인덱스에 올립니다. 그 뒤 작업 파일을 다시 바꾸지 않았다면 기본 diff는 비어 있을 수 있지만, 인덱스와 HEAD의 차이는 남습니다.

조회 명령	비교 범위	읽을 의미
git diff	작업 트리 ↔ 인덱스	아직 스테이징하지 않은 수정
git diff --cached	인덱스 ↔ HEAD	커밋 후보의 변경
git diff HEAD	작업 트리 ↔ HEAD	마지막 커밋 이후의 최종 차이

1. 저장소와 파일 범위를 먼저 확인한다

git --version
git status --short
git diff -- sample.txt
git diff --cached -- sample.txt
git diff HEAD -- sample.txt

저장소 루트와 대상 파일을 확인한 뒤 예제 이름을 실제 경로로 바꾸세요. 위 명령들은 차이를 읽기 위한 예시입니다. --는 파일 경로와 옵션을 구분합니다. untracked 파일은 일반 diff만으로 검토가 끝나지 않으므로 status 결과를 함께 봅니다. 출력에 비밀 값이 있다면 그대로 외부에 공유하지 마세요.

2. 격리된 로컬 시험에서 관찰한 결과

2026년 10월 22일 macOS의 Git 2.50.1(Apple Git-155)에서 별도 임시 저장소를 만들었습니다. sample.txt의 before 줄을 커밋한 뒤 after로 수정했을 때 기본 diff에 변경이 보였습니다. git add 이후에는 같은 기본 diff의 출력이 비었고, --cached와 HEAD 비교에는 before/after 차이가 남았습니다. status --short는 인덱스의 수정 상태를 표시했습니다. 운영 저장소는 변경하지 않았습니다.

3. 다시 수정한 파일은 두 번 나누어 읽는다

스테이징 후 같은 파일을 다시 고치면 커밋 후보와 아직 올리지 않은 변경이 나뉩니다. 기본 diff가 보여 주는 변경만 보고 커밋 전체를 판단하거나, --cached만 보고 최종 작업 파일까지 같다고 가정하지 마세요. 검토할 목적이 다음 커밋인지 현재 파일인지부터 정한 뒤 해당 비교를 선택합니다.

확인과 되돌리기 주의

정상 기준은 diff 하나가 비는 것이 아니라 의도한 내용이 올바른 비교 구간에 나타나는 것입니다. 출력이 없다는 이유로 reset --hard, clean 또는 파일 삭제를 실행하지 마세요. 경로·브랜치·미추적 상태·외부 diff 설정 등 다른 원인도 확인해야 합니다. 이 글은 조회 구분을 다루며 기존 변경을 되돌리거나 강제 푸시하는 절차가 아닙니다.

FAQ

빈 diff면 작업이 없다는 뜻인가요? 선택한 두 상태 사이의 차이가 없다는 뜻입니다. staged·untracked·다른 경로를 함께 확인하세요.

--cached는 파일을 바꾸나요? 여기서는 인덱스와 HEAD의 차이를 읽는 조회 명령입니다.

파일을 다시 수정하면 어떻게 되나요? 같은 파일의 staged 변경과 그 이후 수정이 두 diff에 나뉘어 보일 수 있습니다.

공식 출처와 관련 글

자료 확인일: 2026년 10월 22일. macOS의 격리된 임시 환경에서만 아래 설명의 시험을 수행했습니다. 운영 저장소·외부 서버 변경이나 AWS 배포·성능·요금 시험은 하지 않았습니다.

Git diff 공식 비교 범위

Git Book의 staged/unstaged 설명

관련 글: detached HEAD에서 커밋 보존

직접 생성한 개념 이미지입니다. 실제 서비스 화면이나 구축·성능 시험 결과가 아닙니다.