.gitignore 에 넣었는데 git status 에 계속 뜰 때: 추적만 풀고 파일은 남기는 법When a .gitignore Rule Doesn't Hide a File From git status: Untrack It and Keep the File
.gitignore 에 규칙을 넣고도 수정한 파일이 git status 에 계속 뜨는 독자가, 규칙이 틀린 것이 아니라 파일이 이미 추적 중이라는 것을 알고 한 줄로 추적을 푼다.
시험에서 추적 중인 .env 를 규칙에 넣고 수정하자 status 에 M 으로 계속 떴고, 기본 git check-ignore -v 는 아무것도 출력하지 않았다. git ls-files -ci --exclude-standard 가 규칙에 넣은 네 파일을 찾았고 git rm --cached 뒤에는 디스크 파일이 남은 채 status 가 조용해졌다. 이 커밋을 pull 한 팀원의 수정 안 한 파일은 지워졌다.
저장소 맨 위에서 git ls-files -ci --exclude-standard 로 목록을 보고, 맞으면 -z 와 xargs -0 git rm --cached 로 추적을 풀고 커밋하기 전에 팀원에게 .env 같은 파일을 미리 백업하라고 알려라.
목차
한 줄 요약:
.gitignore는 아직 추적하지 않는 파일에만 듣는 규칙이라, 이미 커밋된 파일은git rm --cached로 추적부터 풀어야git status에서 사라진다.
바로 할 것: 저장소 맨 위 폴더에서 git ls-files -ci --exclude-standard -z | xargs -0 git rm --cached 를 치고 git add .gitignore && git commit -m "추적 해제" 로 마무리한다. 파일은 디스크에 그대로 남지만, 이 커밋을 받는 팀원의 수정 안 한 파일은 지워지니 올리기 전에 아래 “팀원이 이 커밋을 받으면” 절을 먼저 읽는다.
$ echo "KEY=2" >> .env
$ git status --short
M .env.env 를 .gitignore 에 분명히 적었는데 수정하면 이렇게 M 이 뜬다. 규칙을 잘못 쓴 것이 아니다. 그 파일을 예전에 커밋했기 때문이다. Git 공식 문서의 말로는 “Files already tracked by Git are not affected” 이고, 추적을 끊으려면 “use git rm –cached to remove the file from the index” 라고 한다. 여기서 index 는 다음 커밋에 들어갈 파일 목록을 담아 두는 Git 내부 장부다.
규칙은 맞는데 check-ignore 가 아무 말도 안 한다
규칙이 먹는지 보려고 git check-ignore -v .env 를 치면 출력이 없고 종료 코드가 1 이다. 무시되는 파일이 없다는 뜻이라 규칙이 틀렸다고 오해하기 쉽다. 공식 문서는 “tracked files are not shown at all since they are not subject to exclude rules” 라고 적는다. 추적 중인 파일은 처음부터 검사 대상이 아니라는 말이다.
장부를 무시하고 규칙만 보려면 --no-index 를 붙인다.
$ git check-ignore -v --no-index .env build/out.js app.log
.gitignore:1:.env .env
.gitignore:2:build/ build/out.js
.gitignore:3:*.log app.log세 파일 모두 규칙 줄 번호와 함께 나왔다. 규칙은 멀쩡하고, 막힌 곳은 추적 상태다.
추적 중인데 규칙에 걸리는 파일만 골라 본다
git ls-files -ci --exclude-standard 는 “이미 추적 중이면서(-c) 지금 무시 규칙에 걸리는(-i)” 파일만 보여 준다.
$ git ls-files -ci --exclude-standard
.env
app.log
build/out.js
config/local.json시험 저장소에서 규칙에 넣은 네 파일이 정확히 이 네 줄로 나왔고, 규칙에 넣지 않은 main.py 는 빠졌다. 지우기 전에 -n(실제로 하지 않고 보여 주기)을 붙여 한 번 확인한다.
$ git ls-files -ci --exclude-standard -z | xargs -0 git rm --cached -n
rm '.env'
rm 'app.log'
rm 'build/out.js'
rm 'config/local.json'-z 와 xargs -0 는 파일 이름에 공백이나 한글이 있어도 쪼개지지 않게 하는 짝이다. 시험에서 my dir/비밀 설정.txt 가 한 파일로 처리됐다.
추적만 풀고 커밋한다
-n 을 빼고 실행하면 추적 해제가 index 에 올라가 D(staged 삭제)로 보인다.
$ git ls-files -ci --exclude-standard -z | xargs -0 git rm --cached
rm '.env'
rm 'app.log'
rm 'build/out.js'
rm 'config/local.json'
$ git status --short
D .env
D app.log
D build/out.js
D config/local.json
?? .gitignore--cached 가 있어서 ls 로 보면 네 파일 모두 디스크에 그대로 있었다. --cached 를 빼고 git rm 만 쓰면 파일이 디스크에서도 지워진다(git rm keep.txt 뒤 ls: keep.txt: No such file or directory). 이어서 .gitignore 와 함께 커밋한다.
$ git add .gitignore && git commit -m "추적 해제"커밋 뒤에 echo "KEY=3" >> .env 로 다시 고쳐도 git status 는 조용했다. 폴더 하나만 풀려고 git rm --cached dist 를 치면 fatal: not removing 'dist' recursively without -r 로 막히니 폴더는 -r 을 붙인다. 위의 ls-files 방식은 파일 단위로 목록을 만들어 이 오류가 없다. 풀 파일이 하나도 없을 때 같은 줄을 다시 쳐도 오류 없이 끝났다(종료 코드 0).
팀원이 이 커밋을 받으면 파일이 지워진다
여기서 가장 조심할 것이 있다. 추적 해제 커밋을 git pull 로 받은 팀원의 저장소에서, 수정하지 않은 .env 는 사라졌다. 이 파일을 Git 이 지우라는 변경으로 읽기 때문이다. 팀원이 .env 를 자기 값으로 수정해 둔 경우에는 pull 이 Your local changes to the following files would be overwritten by merge 로 멈췄고 파일은 그대로였다. 멈춘 팀원이 이어 가려면 자기 .env 를 다른 곳에 복사하고 git checkout -- .env 로 되돌린 뒤 git pull 을 하고 복사본을 다시 .env 로 놓으면 된다. 시험에서 pull 은 종료 코드 0 으로 끝났고 복사본을 되돌린 .env 는 status 에 뜨지 않았다.
그래서 비밀번호나 개인 설정이 든 파일이라면 커밋을 올리기 전에 팀원에게 .env 를 다른 곳에 복사해 두라고 알려 둔다. 파일 내용 자체는 지난 커밋에 그대로 남는다. 시험에서 추적 해제 뒤에도 git show main~1:.env 가 KEY=1 을 그대로 보여 줬다. 이미 올린 비밀값은 추적을 풀어도 사라지지 않으니 값 자체를 바꾸는 것이 먼저다.
그래도 안 되면 규칙 쪽을 본다
추적을 풀었는데도 안 되거나 새 파일이 무시되지 않는다면 git check-ignore -v --no-index 경로 가 어느 규칙이 걸렸는지 알려 준다. 한 가지 흔한 함정은 폴더를 통째로 막고 하나만 되살리려는 경우다. build/ 와 !build/keep.txt 를 함께 쓰면 git add -n build/keep.txt 가 The following paths are ignored 로 거부했고, build/* 로 바꾸자 add 'build/keep.txt' 가 됐다. 공식 문서도 “It is not possible to re-include a file if a parent directory of that file is excluded” 라고 한다.
시험 범위와 한계
시험은 macOS 26.6.2(arm64)의 Apple Git 2.54.0 에서 합성한 저장소로 했다. 전역·시스템 Git 설정은 끄고(GIT_CONFIG_GLOBAL=/dev/null) 두 스크립트를 각각 두 번 돌려 출력이 같았다. xargs 는 macOS 기본(BSD) 것이다. 리눅스·윈도·GNU xargs 와 서브모듈은 시험하지 않았다. GNU xargs 는 입력이 비어도 명령을 한 번 실행하는 기본값이라 빈 목록일 때 usage 오류가 날 수 있고, 이 줄은 돌려 보지 않았다. 원격 서버에 올린 뒤의 동작과 과거 커밋에서 비밀값을 지우는 방법은 다루지 않았다. 팀원 시험은 로컬 bare 저장소 하나로 했고, 수정 안 한 팀원은 git pull 로, 수정한 팀원은 pull 이 멈춘 뒤 위 복구 순서로 확인했다.
세 줄 요약
.gitignore규칙은 이미 추적 중인 파일에 듣지 않고,git check-ignore -v도 그런 파일은--no-index없이는 보여 주지 않는다.git ls-files -ci --exclude-standard -z | xargs -0 git rm --cached로 추적만 풀고 커밋하면 파일은 디스크에 남고 status 가 조용해진다.- 받는 팀원의 수정 안 한 파일은 지워지고, 지난 커밋의 내용은 남으니 비밀값은 미리 백업과 교체를 알려라.
Help a reader who added a rule to .gitignore but still sees the edited file in git status realize the rule is fine and the file is already tracked, then untrack it with one line.
In the test, a tracked .env listed in the rules kept showing M in status after an edit, and plain git check-ignore -v printed nothing. git ls-files -ci --exclude-standard found the four files that were in the rules, and after git rm --cached the files stayed on disk and status went quiet. A teammate who pulled that commit lost the unmodified file.
From the repository root, list the files with git ls-files -ci --exclude-standard, and if the list is right, untrack with -z and xargs -0 git rm --cached, and before you commit tell teammates to back up files like .env.
Contents
One-line summary:
.gitignoreonly affects files Git is not tracking yet, so a file that is already committed has to be untracked withgit rm --cachedbefore it disappears fromgit status.
Do this now: From the top folder of the repository, run git ls-files -ci --exclude-standard -z | xargs -0 git rm --cached, then finish with git add .gitignore && git commit -m "untrack". The files stay on disk, but a teammate who receives this commit loses unmodified copies, so read the “Teammates who pull this commit” section below before you push.
$ echo "KEY=2" >> .env
$ git status --short
M .envYou wrote .env in .gitignore, yet an edit shows M like this. The rule is not wrong. The file was committed earlier. The Git documentation says “Files already tracked by Git are not affected”, and to stop tracking you “use git rm –cached to remove the file from the index”. The index is Git’s internal list of what goes into the next commit.
The rule is right but check-ignore says nothing
To see whether the rule works you run git check-ignore -v .env, and it prints nothing and exits with 1. That means no path is ignored, which makes it easy to think the rule is broken. The documentation says “tracked files are not shown at all since they are not subject to exclude rules”. Tracked files are simply outside the check.
Add --no-index to ignore the index and look only at the rules.
$ git check-ignore -v --no-index .env build/out.js app.log
.gitignore:1:.env .env
.gitignore:2:build/ build/out.js
.gitignore:3:*.log app.logAll three files came back with the rule line number. The rules are fine; the tracking state is the blocker.
List only the tracked files that match a rule
git ls-files -ci --exclude-standard shows only files that are already tracked (-c) and also match an ignore rule right now (-i).
$ git ls-files -ci --exclude-standard
.env
app.log
build/out.js
config/local.jsonIn the test repository, exactly these four lines came out for the four files that were added to the rules, and main.py, which was not in the rules, was left out. Before removing anything, add -n (show what would happen without doing it) and check once.
$ git ls-files -ci --exclude-standard -z | xargs -0 git rm --cached -n
rm '.env'
rm 'app.log'
rm 'build/out.js'
rm 'config/local.json'-z and xargs -0 are a pair that keeps names with spaces or non-ASCII characters from being split. In the test, my dir/ followed by a Korean file name with a space was handled as one file.
Untrack and commit
Run it without -n and the untracking goes into the index, showing as D (staged deletion).
$ git ls-files -ci --exclude-standard -z | xargs -0 git rm --cached
rm '.env'
rm 'app.log'
rm 'build/out.js'
rm 'config/local.json'
$ git status --short
D .env
D app.log
D build/out.js
D config/local.json
?? .gitignoreBecause of --cached, ls showed all four files still on disk. With plain git rm and no --cached, the file is deleted from disk too (after git rm keep.txt, ls: keep.txt: No such file or directory). Then commit together with .gitignore.
$ git add .gitignore && git commit -m "untrack"After the commit, editing again with echo "KEY=3" >> .env left git status quiet. If you try to untrack one folder with git rm --cached dist, it stops with fatal: not removing 'dist' recursively without -r, so folders need -r. The ls-files approach builds a per-file list and avoids that error. Running the same line again when nothing was left to untrack ended without an error (exit code 0).
Teammates who pull this commit lose the file
Here is the part to be careful about. In a teammate’s repository that pulled the untracking commit with git pull, an unmodified .env disappeared, because Git reads the change as an instruction to delete it. When the teammate had edited .env to their own values, the pull stopped with Your local changes to the following files would be overwritten by merge and the file stayed put. A teammate who got stopped can continue by copying their own .env somewhere else, restoring it with git checkout -- .env, running git pull, and putting the copy back as .env. In the test the pull ended with exit code 0 and the restored .env did not show up in status.
So if the file holds passwords or personal settings, tell teammates to copy .env somewhere else before you push the commit. The contents themselves remain in earlier commits. In the test, git show main~1:.env still printed KEY=1 after the untracking commit. A secret that was already pushed does not go away by untracking, so changing the value comes first.
If it still doesn’t work, look at the rule
If it still fails after untracking, or a new file is not ignored, git check-ignore -v --no-index path tells you which rule matched. One common trap is blocking a whole folder and trying to bring back a single file. With build/ and !build/keep.txt together, git add -n build/keep.txt was refused with The following paths are ignored, and after switching to build/* it became add 'build/keep.txt'. The documentation also says “It is not possible to re-include a file if a parent directory of that file is excluded”.
Test scope and limits
The tests ran on synthetic repositories with Apple Git 2.54.0 on macOS 26.6.2 (arm64). Global and system Git configuration was turned off (GIT_CONFIG_GLOBAL=/dev/null), and each of the two scripts was run twice with identical output. The xargs is the macOS default (BSD) one. Linux, Windows, GNU xargs, and submodules were not tested. GNU xargs runs the command once by default even when the input is empty, so an empty list may produce a usage error, and that line was not run. Behavior after pushing to a remote server and ways to purge a secret from past commits are not covered. The teammate test used a single local bare repository; the teammate with unmodified files used git pull, and the one with edits was checked with the recovery steps above after the pull stopped.
Three-line summary
.gitignorerules do not apply to files that are already tracked, andgit check-ignore -vdoes not show such files without--no-index.git ls-files -ci --exclude-standard -z | xargs -0 git rm --cachedfollowed by a commit untracks the files, leaves them on disk, and quiets status.- A teammate’s unmodified file is deleted on pull and earlier commits keep the contents, so warn them to back up and rotate secrets first.