git worktree remove 오류, modified or untracked files 안전하게 정리하기

git worktree remove 오류가 contains modified or untracked files로 멈추면 --force부터 붙이지 마세요. 그 worktree에 아직 저장하지 않은 수정 파일이나 새 파일이 있다는 뜻입니다. 먼저 status로 파일을 확인합니다. 남길 작업을 커밋하거나 미추적 파일까지 포함해 stash한 뒤 일반 remove를 다시 실행합니다.

실제 Codex 앱 화면이 아니라, 변경 파일을 확인하고 보존한 뒤 제거하는 판단 순서를 설명한 개념도입니다.

force보다 status부터 확인하세요

이 작업은 Codex 웹사이트가 아니라 Mac의 터미널에서 합니다. Command + Space를 누르고 터미널을 열어 아래 명령의 경로를 실제 worktree 폴더로 바꿉니다.

git -C "/worktree/경로" status --short
git -C "/worktree/경로" diff --stat

M notes.txt처럼 보이면 Git이 이미 추적하는 파일이 수정된 상태입니다. ?? draft.txt는 아직 추적하지 않는 새 파일입니다. 출력이 있다면 어떤 파일을 남길지 결정하기 전에는 제거하지 않습니다.

fatal: not a git repository가 나오면 입력한 폴더가 Git 저장소가 아닙니다. Codex에서 사용한 원본 프로젝트나 worktree 폴더를 Finder에서 확인한 뒤 그 경로로 다시 실행하세요.

남길 방법을 먼저 고르세요

완료된 작업이라면 worktree 안에서 검사를 마치고 커밋하는 편이 가장 명확합니다. 아직 커밋하기 이르지만 잠시 보존해야 한다면 추적 파일과 미추적 파일을 함께 stash할 수 있습니다.

git -C "/worktree/경로" stash push --include-untracked -m "preserve before worktree removal"
git -C "/worktree/경로" status --short

두 번째 명령에 아무 파일도 나오지 않아야 clean 상태입니다. --include-untracked를 빼면 ??로 표시된 새 파일은 stash에 들어가지 않을 수 있습니다.

stash가 익숙하지 않거나 이 저장소 밖에서도 파일을 봐야 한다면 필요한 파일을 별도 폴더에 복사하고 실제로 열리는지 확인하는 방법도 있습니다. 다만 복사만 했다는 이유로 원본을 바로 지우지 말고, 필요한 파일과 하위 폴더가 모두 보존됐는지 확인합니다.

clean 상태에서 일반 remove를 다시 실행하세요

원본 저장소 폴더에서 linked worktree 경로를 지정합니다.

git -C "/원본/저장소" worktree remove "/worktree/경로"
git -C "/원본/저장소" worktree list

두 번째 목록에서 제거한 경로가 사라졌다면 worktree 등록과 폴더 정리가 끝난 것입니다. worktree 제거와 브랜치 삭제는 같은 작업이 아닙니다. 브랜치가 남아 있어도 remove 실패를 뜻하지 않습니다.

실제 재현에서 무엇이 달라졌나

재현 결과는 파일 보존 뒤 일반 remove로 돌아갈 수 있음을 보여 줍니다. 2026-09-19에 Git 2.38.1의 비민감 임시 저장소에서 linked worktree의 추적 파일 하나를 수정하고 미추적 파일 하나를 만들었습니다.

 M notes.txt
?? draft.txt

일반 remove는 exit 128과 함께 다음 오류로 멈췄습니다.

fatal: '/tmp/.../worktree' contains modified or untracked files, use --force to delete it

stash push --include-untracked로 두 파일을 보존한 뒤 status가 비었습니다. 일반 remove도 성공했습니다. 재현 뒤 cleanup-test 브랜치와 stash는 남았습니다. 이 결과는 강제 삭제의 안전성을 입증하지 않습니다. 보존 여부를 먼저 정하면 일반 제거로 돌아갈 수 있다는 확인입니다.

언제 –force를 써도 되나요?

파일을 다시 쓸 일이 없고 삭제해도 된다는 점을 직접 확인한 경우에만 고려합니다. 오류 메시지가 안내했다는 이유만으로 안전한 선택이 되지는 않습니다. 특히 status --short의 ?? 파일은 아직 커밋 기록에 없으므로 강제 제거 전에 별도 보존 여부를 반드시 판단하세요.

브랜치가 다른 worktree에서 사용 중이라는 오류라면 원인이 다릅니다. 브랜치를 사용 중인 worktree 경로 찾기를 먼저 보세요.

폴더는 이미 사라졌는데 git worktree list에 경로만 남는다면 remove가 아니라 stale worktree 등록을 dry-run으로 정리하는 순서가 맞습니다.

자주 묻는 질문

stash 뒤 파일은 어디에서 확인하나요?

원본 저장소에서 git stash list를 실행하면 보존한 항목을 확인할 수 있습니다. 필요한 브랜치와 폴더를 준비한 뒤 git stash show --stat으로 파일 목록부터 읽으세요. 바로 적용하기 전에 대상 저장소와 stash 메시지가 맞는지 확인합니다.

remove 뒤 브랜치가 남으면 실패한 건가요?

아닙니다. git worktree remove는 linked worktree 등록과 해당 작업 폴더를 제거합니다. 브랜치 삭제는 별도 판단입니다. git branch --list cleanup-test처럼 실제 브랜치 이름을 넣어 남아 있는지 확인한 뒤 유지하거나 별도로 정리하세요.

검증 기준

• 마지막 업데이트일: 2026-09-19
• 확인 환경: macOS, Git 2.38.1, 비민감 임시 저장소
• 주요 근거: Git git-worktree 공식 문서 · Git git-stash 공식 문서
• 확인 범위: 추적 파일 수정+미추적 파일 생성 → 일반 remove 거부 → 미추적 포함 stash → clean 상태 → 일반 remove 성공 → 브랜치·stash 유지
• 미확인: 정확 월간 검색량, seoin.dev 독자의 직접 피드백, Codex Desktop 각 버전의 UI 제거 동작
• 이 글은 CLI 입력·출력 판정이 핵심인 개념형 오류 가이드다. 실제 Codex 앱 조작을 했다고 주장하지 않는다.
• 대표이미지와 alt, strict SEO94/AEO90, gpt-5.6-sol low 독립 최종검수를 통과했다. 다음 적격 발행일의 fresh 서버·보호·cadence 게이트는 아직 남았다.

참고: Git 공식 worktree 문서