핵심 정리
git status
# 보고 판단하기
- Changes not staged for commit
- Changes to be committed
- Untracked files읽는 법
어떤 상태를 먼저 읽으면 되나
| 상황 | 먼저 볼 것 |
|---|---|
| 커밋에 들어갈 예정인 변경 | Changes to be committed |
| 아직 스테이징 안 한 변경 | Changes not staged for commit |
| Git이 아직 추적하지 않는 새 파일 | Untracked files |
| 빠르게 상태 코드만 확인 | git status -s |
git status는 세 영역의 상태를 동시에 보여 주는 진단 명령이다
Git은 파일을 세 영역으로 관리합니다. HEAD commit이 가리키는 tree 객체(마지막 커밋 상태), 인덱스(스테이징 영역), 그리고 작업 트리(실제 파일)입니다. git status는 이 세 영역의 차이를 한번에 보고합니다. "Changes not staged"는 작업 트리가 인덱스와 다른 파일, "Changes to be committed"는 인덱스가 HEAD와 다른 파일, "Untracked files"는 인덱스에 없는 새 파일입니다. 세 영역의 개념을 이해하면 상태 메시지가 훨씬 직관적으로 읽힙니다.
$ git status
On branch main
Changes to be committed: ← 인덱스가 HEAD와 다름 (staged)
modified: src/app.js
Changes not staged for commit: ← 작업 트리가 인덱스와 다름
modified: src/utils.js
Untracked files: ← 인덱스에 없는 새 파일
docs/ideas.md"Changes not staged"와 "Changes to be committed"를 혼동하면 빠뜨린 파일로 커밋이 불완전해진다
git add를 하지 않으면 파일이 수정되어도 다음 커밋에 포함되지 않습니다. 반대로 git add는 했지만 이후 추가로 수정하면 수정된 내용은 "staged" 상태가 아니라 "not staged"로 다시 표시됩니다. 이 두 상태의 차이를 인식하지 못하면 커밋에 의도한 변경 일부만 들어가거나, 디버그 코드가 staged 상태로 남아 커밋에 섞이는 실수가 생깁니다. git diff --staged로 실제 커밋 예정 내용을 확인하는 습관이 필요합니다.
git status # 전체 상태 파악
git diff # not staged 변경 내용 확인
git diff --staged # staged 변경 내용 확인 (커밋 예정)
git add src/utils.js # 특정 파일 스테이징git status -s는 반복 작업에서 노이즈를 줄이는 압축 출력이다
기본 git status는 사람이 처음 읽기에 친절하지만, 반복 작업에서는 출력이 길어 불편합니다. -s(short) 옵션은 파일당 두 글자 상태 코드로 압축 출력합니다. 왼쪽 열은 인덱스 상태, 오른쪽 열은 작업 트리 상태를 나타냅니다. M은 modified, A는 추가됨, ?는 untracked입니다. 상태를 빠르게 훑고 이어서 git add나 git diff로 넘어가는 반복 패턴에서 -s가 더 효율적입니다.
git status -s
M src/app.js # staged modified (왼쪽 M)
M src/utils.js # unstaged modified (오른쪽 M)
?? docs/ideas.md # untrackedstaged 뒤에 다시 수정하면 커밋 내용과 현재 파일 내용이 달라진다
많이 헷갈리는 상황이 git add를 한 뒤 파일을 다시 고친 경우입니다. 이때 커밋에 들어가는 것은 마지막으로 add한 시점의 내용이고, 그 뒤 수정분은 아직 작업 트리에만 남아 있습니다. git status에서 같은 파일이 staged와 not staged에 동시에 보이면, 커밋 직전 git add를 한 번 더 해야 현재 파일 상태가 전부 들어갑니다.
git add src/app.js
# 이후 src/app.js를 다시 수정
git status
# Changes to be committed: src/app.js
# Changes not staged for commit: src/app.js
git diff --staged # 지금 커밋에 들어갈 내용
git diff # add 이후 추가로 바뀐 내용
git add src/app.js # 현재 파일 상태를 다시 staged로 반영체크포인트
| 상황 | 적합한 선택 |
|---|---|
| 현재 작업 상태 전체 파악 | git status |
| 반복 작업 중 빠른 상태 확인 | git status -s |
| staged와 작업 트리 상태를 한 파일 기준으로 함께 확인 | git status -s의 왼쪽/오른쪽 상태 코드 |
| not staged 변경 내용 확인 | git diff |
| staged(커밋 예정) 변경 내용 확인 | git diff --staged |
| 작업 트리가 HEAD와 동일한 상태 | nothing to commit, working tree clean |
주의할 점
git status를 읽지 않고 바로 git commit이나 git push로 넘어가면 의도하지 않은 파일이
커밋에 포함되거나 꼭 필요한 변경이 빠지는 실수가 생깁니다. 특히 git add 후 파일을 추가로
수정하면 수정된 내용이 staged 상태가 아니므로 커밋에서 누락됩니다. 커밋 직전에는 반드시
git status와 git diff --staged를 함께 확인하는 습관이 필요합니다.
참고 링크
1 sources