.gitignore에 넣었는데 계속 올라갈 때: Git 추적 상태를 확인하는 순서

👤 인스피

조회 수 6

2. 세 상태를 나누어 보면 이해하기 쉽습니다

작업 폴더에는 파일이 존재할 수 있고, Git의 인덱스에는 다음 커밋에 포함할 상태가 기록될 수 있습니다. 기존 커밋 기록에는 과거 파일 내용이 남아 있을 수 있습니다. 하나의 명령이 이 세 위치를 모두 지운다고 생각하면 실수하기 쉽습니다.

.gitignore는 아직 추적하지 않는 파일의 포함을 막는 데 사용합니다. git rm --cached는 지정한 파일을 인덱스에서 제거하고 작업 폴더의 파일은 남깁니다. 이 상태를 커밋해도 기존 커밋 안의 내용까지 사라지는 것은 아닙니다. 운영 프로젝트를 수정하기 전에 현재 상태와 백업을 확인하는 이유입니다.

3. 먼저 어떤 규칙이 적용되는지 확인합니다

git status --short로 현재 변경을 확인하고 git ls-files로 추적 목록을 살펴봅니다. 무시 대상이 아직 추적되지 않았다면 git check-ignore -v로 적용된 규칙 위치를 볼 수 있습니다. 규칙 파일이 프로젝트 루트인지 하위 폴더인지에 따라서 경로 해석이 달라질 수 있습니다.

이미 추적한 파일에 대해 check-ignore 결과가 없으면 무시 규칙이 반드시 틀렸다는 뜻은 아닙니다. 이때는 ls-files 결과를 우선 대조합니다. 파일 이름에 공백이 있으면 명령에서 따옴표를 사용하세요. 운영 환경의 실제 인증 값이나 설정 내용은 진단 화면에 붙여 넣지 않아도 됩니다.

4. 새 연습 폴더에서 최소 사례를 만듭니다

Windows 명령 프롬프트에서 다음 순서를 실행합니다. 같은 이름의 폴더가 이미 있으면 다른 새 폴더를 사용합니다. git add는 인덱스에 추가하는 명령이므로 실습에는 커밋 작성자 설정이나 원격 주소가 필요하지 않습니다. 예제는 실제 .env를 덮어쓰지 않도록 새 폴더에서 진행해야 합니다.

핵심 비교는 .gitignore를 만든 직후에도 ls-files에 .env가 나온다는 점입니다. 다음에 --cached 옵션으로 파일만 추적에서 제거합니다. 이 옵션을 빼고 실행하는 것과 구분하세요. 마지막에는 폴더 안의 .env가 남아 있는지 직접 확인합니다. 의미를 이해한 뒤 운영 저장소에 적용하는 편이 안전합니다.

5. 프로젝트에 적용할 때는 파일 단위로 처리합니다

인터넷 예제에는 전체 인덱스를 지웠다가 다시 추가하는 명령이 자주 등장합니다. 하지만 현재 작업 중인 변경과 불필요한 파일을 한꺼번에 건드릴 수 있으므로 문제 파일을 지정하는 작은 변경부터 검토하세요. 명령을 실행한 뒤에는 git diff --cached로 커밋에 들어갈 변경을 확인합니다.

의도한 파일 삭제 기록과 .gitignore 추가만 포함되는지 살펴봅니다. 다른 개발자의 변경이나 자동 생성 파일이 섞여 있으면 곧바로 커밋하지 말고 상태를 정리하세요. 로컬 파일을 보존했다는 사실과 저장소 기록에서 제외됐다는 사실을 각각 확인하면 변경의 범위를 분명히 설명할 수 있습니다.

6. 이미 비밀 값이 올라갔다면 별도 문제입니다

추적을 해제하는 작업은 앞으로의 포함을 줄일 뿐, 공개된 인증 값을 비공개로 되돌리지 않습니다. 실제 키가 노출된 경우 해당 서비스에서 키 폐기와 교체를 우선 검토해야 합니다. 과거 기록 정리는 저장소를 함께 사용하는 사람에게 영향을 줄 수 있으므로 별도 절차로 다룹니다.

이 글은 기록 재작성이나 강제 푸시를 안내하지 않습니다. 문제를 해결했다는 판단도 현재 변경 목록만 보고 하지 마세요. 기록, 원격 저장소, 배포 환경에 어떤 값이 들어갔는지 따로 확인해야 합니다. 연습용 파일로 무시 규칙을 이해한 뒤 프로젝트의 정책에 맞게 적용하세요.

7. 변경 검토를 위한 작은 연습 시나리오

연습 폴더에서 .env 외에 app.py와 notes.txt도 만든 뒤 상태를 비교해 보세요. app.py는 일반 코드 파일이고 .env는 무시 대상입니다. 두 파일을 동시에 추가했다면 추적 해제 명령을 .env에만 적용하고 app.py의 상태는 그대로인지 확인합니다. 전체 파일을 한꺼번에 처리하는 것보다 변화의 의미가 잘 드러납니다.

규칙에 .env를 적는 경우와 특정 하위 경로를 적는 경우도 다른 새 폴더에서 시험할 수 있습니다. 같은 이름의 파일이 여러 위치에 있으면 어떤 패턴이 적용되는지 check-ignore 출력으로 확인합니다. 프로젝트의 실제 설정에 맞게 선택해야 하며 패턴 하나가 모든 상황의 정답이라고 볼 수 없습니다. 원하는 파일이 포함됐는지보다 제외해야 할 파일이 남았는지도 살펴봅니다.

작업이 끝나면 현재 추적 목록, 스테이징 변경과 로컬 파일 존재를 각각 기록합니다. 이 세 결과가 의도와 맞는지 확인한 뒤 운영 저장소에 적용하세요. 작업 폴더에는 남기되 저장소에서는 빼려는 설정 파일과, 실제로 삭제하려는 불필요 파일은 서로 다른 작업입니다. 이름이 비슷하다고 같은 명령을 반복하지 않습니다.

공동 작업 저장소에서는 변경 이유를 간단히 설명하는 것이 도움이 됩니다. 예를 들어 개발자마다 다른 로컬 설정 파일을 제외하고, 필요한 형식은 실제 값 없는 예제 파일로 제공할 수 있습니다. 예제 파일의 목적은 다른 사람이 어떤 값을 준비해야 하는지 알게 하는 것이지 실제 인증 값의 복사본을 배포하는 것이 아닙니다. 의존하는 배포 과정도 확인하세요.

되돌릴 때는 현재 작업이 커밋 전인지 후인지부터 구분합니다. 이 글의 최소 실습은 커밋 전 인덱스 상태만 다룹니다. 이미 푸시한 공동 기록을 바꾸는 작업은 별도 영향이 있으므로 여기의 명령을 확대하지 마세요. 최근 변경을 확인한 결과를 근거로 처리하면 비밀 값 대응과 무시 규칙 정리를 혼동하지 않을 수 있습니다.

8. 따라 하는 예제

명령과 코드는 학습용입니다. 설명에 표시된 실행 환경을 구분하고 새 시험 폴더 또는 모의 입력으로 시작하세요.

예제 코드

mkdir git-ignore-demo
cd git-ignore-demo
git init
echo DEMO=not-a-secret>.env
git add .env
echo .env>.gitignore
git ls-files -- .env

git rm --cached -- .env
git check-ignore -v .env
git status --short

type .env

9. 검증 결과와 해석

확인 항목	결과 또는 검증 범위
무시 규칙 추가 직후	.env가 추적 목록에 남음
git rm --cached 이후	.env가 무시 대상
로컬 파일	존재함
원격 작업	실행하지 않음

격리된 임시 Git 저장소에서 추적 추가, 무시 규칙 추가, 추적 해제와 로컬 파일 보존을 확인했습니다. 본문의 파일 생성 명령은 Windows CMD용이며 동일 절차의 Git 동작은 Linux에서 검증했습니다.