Git status 읽기: 수정·스테이징·추적되지 않은 파일 구분

파일 수정부터 커밋 준비까지

STEP 1	현재 파일 수정·저장
STEP 2	status로 상태 확인
STEP 3	diff로 미준비 변경 확인
STEP 4	필요한 파일 스테이징
STEP 5	cached diff로 준비 내용 확인

읽는 순서를 정리한 설명 도해입니다. 실제 프로그램 화면이나 측정 결과가 아닙니다.

Git을 처음 사용하면 파일을 저장했는데도 “커밋할 변경 없음”이 나오거나, 분명 수정한 파일이 두 목록에 동시에 나타나 당황할 수 있습니다. 이런 상황을 이해하려면 현재 파일, 다음 커밋에 담을 내용, 마지막 커밋을 나눠 생각해야 합니다. git status는 이 차이를 읽는 기본 도구입니다.

여기서는 일반적인 Git 저장소에서 수정·스테이징·추적되지 않은 파일을 구분하는 방법을 설명합니다. 명령과 출력은 이해를 위한 가상 예시이며 실제 독자의 저장소에서 실행한 결과가 아닙니다. 변경을 지우는 명령으로 시작하지 않고, 먼저 상태와 차이를 확인하는 절차에 집중합니다.

1. 작업 디렉터리, 스테이징 영역, 커밋 구분하기

작업 디렉터리는 편집기에서 현재 읽고 수정하는 파일이 있는 공간입니다. 스테이징 영역은 다음 커밋에 포함할 내용을 모아 둔 상태이며 인덱스라고도 부릅니다. 마지막 커밋은 이미 기록한 스냅샷입니다. git status는 이 상태들 사이의 차이와 추적되지 않은 파일 등을 보여 줍니다. 저장 버튼을 눌렀다는 사실과 Git 커밋에 기록했다는 사실은 다릅니다.

git add는 현재의 변경 내용을 다음 커밋에 담을 준비를 하는 동작입니다. 준비한 뒤 같은 파일을 또 수정하면 스테이징 영역과 현재 파일이 달라질 수 있습니다. 이 경우 한 파일이 커밋할 변경 목록과 아직 스테이징하지 않은 변경 목록에 함께 나타날 수 있습니다. 오류로 단정하지 말고 각각의 차이를 확인해야 합니다.

가상의 note.txt에 첫 문장을 쓰고 스테이징한 뒤 두 번째 문장을 추가했다고 해 보세요. 다음 커밋에 준비된 내용은 첫 단계의 파일이고, 작업 디렉터리에는 추가 문장이 있는 상태입니다. 두 번째 문장도 이번 커밋에 넣으려면 현재 변경을 확인한 다음 다시 스테이징해야 합니다. 파일명 하나가 있다고 그 파일의 최신 내용 전체가 준비된 것은 아닙니다.

2. 저장소 위치를 확인하고 기본 상태 읽기

먼저 터미널이 올바른 프로젝트 안에 있는지 확인합니다. 다른 폴더에서 명령을 실행하면 의도한 저장소의 상태를 보지 못할 수 있습니다. Git 저장소가 아니라는 오류가 나오면 곧바로 새 저장소를 만들기보다 현재 경로와 원래 프로젝트 폴더를 확인하세요. 프로젝트 자체에 이미 Git 기록이 있다면 그 위치에서 상태를 읽는 것이 먼저입니다.

기본 명령은 git status입니다. 일반 출력에서는 현재 브랜치와 준비된 변경, 아직 준비하지 않은 변경, 추적되지 않은 파일 등의 목록을 읽을 수 있습니다. 언어나 설정, 진행 중인 작업에 따라 문구가 달라질 수 있으므로 목록의 의미를 확인합니다. 이 글의 영어 표현이 내 화면과 다르다고 기능이 달라졌다고 판단할 필요는 없습니다.

가상 출력에서 “Changes to be committed”는 다음 커밋에 준비된 변경, “Changes not staged for commit”은 현재 파일과 준비된 내용 사이의 변경, “Untracked files”는 아직 Git이 추적하지 않는 파일을 나타냅니다. 목록에 있던 파일을 열어 본 뒤 어떤 변경을 이번 작업에 포함할지 결정하세요. 모든 파일을 한꺼번에 추가하기 전에 목적을 확인하는 것이 좋습니다.

git status
git diff
git diff --cached

위 세 명령은 상태와 차이를 읽기 위한 기본 예시입니다. git diff는 보통 스테이징하지 않은 변경을, git diff --cached는 마지막 커밋과 비교한 스테이징 내용을 확인하는 데 사용합니다. 실제 명령의 상세 동작과 옵션은 현재 Git 공식 문서를 확인합니다.

일반 목록	뜻	먼저 할 확인
커밋할 변경	다음 커밋에 준비된 내용	git diff --cached로 실제 내용 확인
스테이징되지 않은 변경	현재 파일과 준비된 내용의 차이	git diff로 확인
추적되지 않은 파일	아직 인덱스에 추가되지 않은 파일	필요한 소스인지 임시·생성 파일인지 확인
충돌 관련 상태	병합 과정에서 정리가 필요한 항목	충돌 내용과 진행 작업을 먼저 확인

3. 짧은 출력의 두 칸은 서로 다른 비교다

git status --short를 실행하면 파일 앞에 두 문자 상태가 나타납니다. 일반적인 비충돌 상황에서 첫 번째 칸 X는 인덱스의 상태, 두 번째 칸 Y는 작업 디렉터리의 상태를 나타냅니다. 같은 M이어도 위치가 다르면 의미가 다릅니다. 공백도 의미가 있으므로 두 칸을 하나의 문자처럼 합쳐 읽지 않습니다.

가상 출력 “M app.py”는 첫 칸에 M이 있는 예이고, “ M app.py”는 두 번째 칸에 M이 있는 예입니다. “MM app.py”라면 준비된 변경과 그 이후의 작업 디렉터리 변경이 함께 있을 수 있습니다. 이런 상태에서 커밋하면 현재 파일의 모든 변경이 자동으로 담긴다고 생각하지 말고 스테이징 차이를 직접 확인해야 합니다.

추적되지 않은 파일은 ??로 표시됩니다. A는 추가, D는 삭제, R은 이름 변경 등으로 나타날 수 있습니다. 진행 중인 병합 충돌에서는 같은 두 칸이 별도 규칙으로 해석되므로 일반 규칙만으로 읽지 않습니다. U나 unmerged 관련 안내가 보이면 공식 상태표와 충돌 해결 안내를 확인하고 진행 중인 작업부터 파악합니다.

가상 짧은 출력	일반적인 비충돌 상황의 해석	확인할 차이
M app.py	수정 내용이 스테이징됨	커밋에 준비된 변경
M app.py	작업 디렉터리에서 수정됨	아직 준비하지 않은 변경
MM app.py	스테이징 이후 추가 수정이 있음	두 종류의 변경을 각각 확인
A new.txt	새 파일이 스테이징됨	파일 내용과 포함 목적
?? temp.txt	추적되지 않은 파일	추적할지 무시할지 판단

4. 새 파일이 안 보일 때 확인할 것

새 파일을 만들었는데 목록에 없으면 파일을 실제로 저장했는지와 프로젝트 경로를 먼저 확인합니다. 다음으로 무시 규칙에 포함되었는지 볼 수 있습니다. .gitignore에 맞는 파일은 보통 추적되지 않은 파일 목록에서 제외됩니다. 상태 출력의 옵션이나 설정이 추적되지 않은 파일을 숨기고 있는 경우도 있으므로 현재 명령과 설정을 확인해야 합니다.

무시 규칙은 파일의 목적을 기준으로 판단합니다. 빌드 결과, 캐시, 환경별 설정 등은 프로젝트 정책에 따라 제외할 수 있습니다. 반대로 기능 구현에 필요한 소스 파일이 의도치 않게 무시되었다면 규칙을 검토해야 합니다. 새 파일이 보이지 않는다는 이유로 무시 파일 전체를 강제로 추가하기보다 어떤 규칙과 파일이 관련되는지 알아보는 편이 좋습니다.

추적 중인 파일은 .gitignore에 이름을 넣었다고 자동으로 추적에서 빠지는 것이 아닙니다. 이미 기록한 파일과 아직 추적하지 않은 파일의 처리 방식이 다릅니다. 민감한 값이 있는 파일을 실수로 추적했다면 단순히 목록에서 숨기는 것으로 과거 기록의 노출 문제가 해결된다고 생각하면 안 됩니다. 상황에 맞는 저장소 관리와 해당 자격 증명 조치가 필요할 수 있습니다.

5. 파일 하나를 읽고 준비하는 작은 순서

가상 작업에서 app.py 하나를 수정했다면 먼저 git status로 상태를 확인하고 git diff -- app.py로 변경 내용을 읽습니다. 필요한 변경임을 확인한 다음 git add -- app.py로 준비할 수 있습니다. 이후 git diff --cached -- app.py로 다음 커밋에 담을 내용이 맞는지 읽고, 다시 git status를 확인합니다.

이 순서는 새 파일이나 큰 작업에서도 기본 원리는 같습니다. 다만 새 파일의 내용, 생성된 결과물, 여러 파일의 의존 관계를 함께 봐야 할 수 있습니다. 파일별로 준비한다고 기능이 서로 분리되는 것은 아니므로 하나의 기능에 필요한 변경 묶음을 생각합니다. 반대로 다른 작업의 변경까지 함께 담기지 않도록 범위도 확인하세요.

커밋 전에는 변경 내용을 확인한 뒤 해당 기능에 필요한 검증을 수행합니다. status가 깨끗하다는 사실은 테스트가 통과했다는 뜻이 아닙니다. 커밋되었다는 사실도 실행 결과가 정확하다는 보장이 아닙니다. 상태 확인은 무엇을 기록할지 관리하는 단계이고, 기능 확인은 코드가 요구한 동작을 하는지 판단하는 별도 단계입니다.

6. 자주 헷갈리는 세 상황

첫째, 편집기에서 저장했지만 스테이징하지 않으면 준비된 변경은 없을 수 있습니다. 둘째, 스테이징한 뒤 파일을 다시 수정하면 두 목록에 함께 나타날 수 있습니다. 셋째, 추적되지 않은 새 파일은 커밋 전에 추가하지 않으면 이번 커밋에 들어가지 않습니다. 세 상황 모두 파일명만 보기보다 인덱스와 현재 내용의 차이를 확인하면 이해하기 쉽습니다.

가상의 팀 작업에서 다른 사람이 만든 파일이 상태 목록에 있으면 자신의 변경이라고 바로 판단하지 않습니다. 누가 어떤 작업을 진행 중인지와 현재 체크아웃의 변경을 확인합니다. 상태를 깨끗하게 만들겠다는 이유만으로 목록의 변경을 삭제하거나 되돌리면 필요한 작업을 잃을 수 있습니다. 상태 목록은 지울 목록이 아니라 현재 작업을 이해할 자료입니다.

병합, 리베이스, 충돌 정리 같은 진행 작업이 있으면 일반적인 수정 작업과 구분합니다. status가 제시하는 진행 상황과 관련 파일을 읽고 어떤 단계인지 파악합니다. 명령의 의미를 모른 채 안내에 나온 여러 동작을 연속 실행하기보다 작업의 목적과 보존할 변경을 먼저 확인하세요. 읽기 명령으로 확인하는 단계는 다음 선택의 근거를 마련합니다.

커밋 전에 남길 짧은 기록

“현재 브랜치, 이번 작업에 포함할 파일, 스테이징 차이 확인, 기능 검증 결과, 아직 준비하지 않은 변경”을 메모하면 다음 작업으로 넘어가기 쉽습니다. 파일이 두 목록에 함께 있다면 이후 수정이 무엇인지 적어 둡니다. 미포함 변경이 남아 있어도 의도한 상태라면 그 이유를 기록할 수 있습니다.

한 번에 외울 핵심은 세 가지입니다. 파일 저장은 현재 파일의 저장, git add는 다음 커밋의 준비, 커밋은 준비한 내용을 기록하는 단계입니다. git status를 읽을 때 각 목록과 두 칸의 의미를 연결하면, 새 파일과 수정 파일이 어떤 상태인지 구분하고 필요한 변경을 신중하게 기록할 수 있습니다.

공식 자료와 확인 범위

• Git 공식 git-status 문서
• Pro Git: Recording Changes to the Repository

자료 확인일: 2026년 10월 5일. AI가 공식 자료를 확인하여 작성했습니다. 본문의 가상 사례와 계산 예시는 실제 사용자 기록이나 실험 결과가 아닙니다. 서비스 조건·메뉴 및 공개 자료는 변경될 수 있으며, 필요한 조건은 현재 공식 안내에서 확인합니다.