git diff 결과가 비어 있을 때 --cached로 스테이징 변경 확인 방법

git add 뒤에 git diff가 아무것도 보여 주지 않는다면, 변경이 사라졌다고 판단하기 전에 git diff --cached를 확인하세요. 기본 diff는 작업 파일과 스테이징 영역을 비교하므로 이미 올린 변경은 나오지 않습니다. 더 주의할 상황도 있습니다. 파일을 원래 내용으로 되돌려 git diff HEAD가 비어 있어도, 스테이징 영역에는 다른 내용이 남을 수 있습니다.[1]

파일을 고치기 전에 비교 대상을 확인합니다

HEAD는 현재 커밋, 인덱스는 다음 커밋에 넣으려고 준비한 내용, 작업 트리는 디스크에서 편집하는 파일입니다. git add는 실행한 시점의 파일 내용을 인덱스에 반영합니다. 그 뒤 파일을 다시 저장해도 인덱스가 자동으로 따라 바뀌지는 않습니다.[2] 아래 명령은 저장소 루트에서 실행하며 settings.txt는 확인할 파일 경로로 바꿉니다.

git --version
git status --short --untracked-files=all
git diff -- settings.txt
git diff --cached -- settings.txt
git diff HEAD -- settings.txt

세 diff는 비교 기준이 다릅니다. 첫 번째는 인덱스와 작업 파일, 두 번째는 HEAD와 인덱스, 세 번째는 HEAD와 작업 파일을 비교합니다. --staged는 --cached와 같은 옵션입니다.[1] 이 조회 명령들은 파일 내용이나 커밋 이력을 되돌리지 않습니다. 빈 화면을 없애려고 먼저 파일을 초기화할 이유는 없습니다.

HEAD에는 10, 인덱스에는 20, 파일에는 다시 10

macOS의 git version 2.54.0 (Apple Git-157)에서 별도 임시 저장소로 확인했습니다. 실제 업무 파일은 건드리지 않았습니다. 기준 커밋의 settings.txt에는 limit=10 한 줄을 넣었습니다. 이를 limit=20으로 수정해 git add한 직후에는 기본 diff가 비었지만, --cached에는 10을 지우고 20을 넣는 변경이 나왔습니다.

여기서 파일을 limit=10으로 다시 저장하되 git add는 하지 않았습니다. 추적하지 않는 notes.txt도 하나 만들었습니다. status 결과는 아래와 같았습니다.

MM settings.txt
?? notes.txt

병합 충돌이 없는 일반 파일에서 첫 M은 HEAD와 인덱스의 차이, 두 번째 M은 인덱스와 작업 파일의 차이를 나타냅니다. ??는 아직 추적하지 않는 파일입니다.[3] 두 M을 보고 같은 변경이 중복 표시됐다고 해석하면, 서로 다른 내용을 놓칩니다. 아래에는 실제 비교 결과에서 변경 줄만 추렸습니다. 기본 표시에서 -는 비교 전 내용, +는 비교 후 내용을 나타냅니다. 같은 숫자라도 어떤 두 대상을 비교하느냐에 따라 부호가 뒤바뀝니다.[1]

# git diff -- settings.txt
-limit=20
+limit=10

# git diff --cached -- settings.txt
-limit=10
+limit=20

# git diff HEAD -- settings.txt
# 출력 없음

마지막 결과가 비어 있는 이유는 HEAD와 작업 파일이 모두 limit=10이기 때문입니다. 중간의 인덱스에는 limit=20이 그대로 남아 있습니다. git diff HEAD를 두 종류의 변경을 빠짐없이 나열하는 명령으로 이해하면 이 상태를 놓칩니다. 이 예시에서 아무것도 더 스테이징하지 않고 일반 git commit을 실행하면 준비된 20이 커밋 대상입니다.[1][2]

어느 쪽 내용이 맞는지 헷갈릴 때는 저장된 내용을 직접 읽어 볼 수 있습니다. 아래 출력도 같은 임시 저장소에서 확인했습니다. 콜론 앞에 HEAD를 붙이면 커밋 속 파일을, 콜론으로 시작하면 인덱스 속 파일을 가리킵니다.[4]

git show HEAD:settings.txt
# limit=10
git show :settings.txt
# limit=20

현재 파일을 커밋할지 결정한 뒤 스테이징합니다

의도한 값이 현재 파일의 10이라면 파일 내용을 확인한 다음 해당 경로만 다시 추가합니다. 이 단계는 조회가 아니라 인덱스를 바꾸는 작업입니다. 파일 전체가 반영되므로 일부 변경만 골라 올려 두었다면 그대로 실행하지 마세요.[2]

git add -- settings.txt
git diff --cached -- settings.txt
git diff -- settings.txt
git status --short --untracked-files=all

예시에서는 두 diff가 모두 비었고 status에는 ?? notes.txt만 남았습니다. settings.txt의 HEAD·인덱스·작업 파일이 모두 10으로 같아졌기 때문입니다. notes.txt를 추가하거나 삭제한 것은 아닙니다. 반대로 준비해 둔 20이 맞다면 빈 화면을 만들 목적으로 다시 add하지 말고, --cached의 내용을 검토한 뒤 커밋 여부를 결정하세요.

한 파일의 빈 결과로 저장소 전체를 판단하지 않습니다

• 커밋 직전에는 git diff --cached --name-status로 준비된 파일 목록을 확인합니다. 본문 예시처럼 경로를 지정한 조회는 다른 파일의 변경을 보여 주지 않습니다.[1]
• 새 파일은 status의 ?? 항목도 확인합니다. diff에 내용이 안 보인다고 파일이 없거나 커밋에 포함됐다고 판단하지 않습니다.[3]
• 이 예시는 기존 커밋이 있고 충돌·서브모듈이 없는 일반 텍스트 파일을 전제로 합니다. 충돌 중인 status의 두 글자는 다른 의미이므로 MM 설명을 그대로 적용하지 않습니다.[3]

진단할 때는 status와 diff 결과, 실제 커밋하려는 내용을 함께 확인하세요. softmoa.com의 개발·운영 시스템 구축에서도 검토한 변경과 반영할 대상을 구분하는 절차를 설계합니다.

명령 확인 자료

• [1] Git 공식 문서 — diff 비교 대상과 경로 제한
• [2] Git 공식 문서 — add 시점의 내용과 커밋 대상
• [3] Git 공식 문서 — short 형식과 미추적 파일
• [4] Git 공식 문서 — HEAD:path와 :path 표기

소프트모아는 해당 시스템을 구축합니다. 문의하기