기술 · 실용 가이드
Git worktree 경로가 없나요? prune 전에 repair 또는 lock 하세요
누락은 이동, 일시 오프라인, 실제 삭제를 뜻할 수 있습니다. worktree별 HEAD와 index를 보존한 뒤 분류하고 repair, lock, prune을 선택하세요.
linked worktree 등록 경로가 없다는 사실만으로 메타데이터를 지워도 되는 것은 아닙니다. 디렉터리 이동, 공유 저장소 오프라인, 실제 폐기가 같은 증상을 만듭니다.
정리 전에 worktree 관리 디렉터리와 접근 가능한 파일을 보존하세요. 이동이면 수리하고, 간헐 저장소면 잠그고, 실제로 오래된 등록만 prune 하세요.
1. 정리 전에 증거를 고정하세요
정상 worktree에서 git worktree list --porcelain -z를 실행해 path, HEAD, branch, locked, prunable을 저장합니다. 공통 Git 디렉터리와 해당 관리 디렉터리를 찾고 gitdir, HEAD, index 해시와 정지 상태 복사본을 남깁니다.
접근 가능한 작업 디렉터리와 untracked 파일도 보존합니다. 브랜치 팁은 공유 기록이지만 unstaged 내용은 작업 디렉터리에, staged 상태는 개별 index에 있습니다.
2. 누락 경로를 분류하세요
다른 위치에 있으면 이동, 이동식·네트워크·임시 마운트면 일시 오프라인, 담당자가 미커밋 작업도 필요 없다고 확인했을 때만 실제 삭제입니다.
prune을 탐색 도구로 쓰지 마세요. 잘못된 절대 back-pointer 때문에 컨테이너/호스트 경계의 활성 worktree도 오래된 것처럼 보일 수 있습니다.
3. 이동은 repair하고 간헐 경로는 lock하세요
이동한 linked worktree는 새 경로를 repair에 전달한 뒤 gitdir, HEAD, branch를 증거와 비교합니다.
간헐 저장소는 접근 가능할 때 이유와 함께 lock합니다. locked 파일은 prune을 막으며 경로가 돌아오고 일반 Git 명령이 성공한 뒤에만 해제합니다.
4. staged 상태로 수리를 검증하세요
status와 git diff --cached를 다시 실행하고 예상 브랜치나 detached HEAD와 일반 객체 읽기를 확인합니다. 승인 전에 증거 복사본을 덮어쓰지 마세요.
Git 2.51.1 실험에서 이동 후 이전 등록은 prunable이 되었고 dry-run이 삭제를 제안했습니다. repair는 staged 추가 파일을 보존했고 사전 lock 후 오프라인 상태는 prune 후보가 아니었습니다.
5. 증명된 오래된 등록만 prune하세요
실제로 불필요함을 증명한 뒤 --dry-run --verbose의 각 후보를 증거 장부와 맞추고 정리합니다. 경로가 있을 때는 worktree remove를 우선합니다.
이미 prune했다면 추가 정리를 멈추고 작업 파일, 공유 객체, reflog를 보존합니다. fsck는 객체 상태를 보고하지만 자동 복구 버튼은 아닙니다.
