오래된 보관본을 정리하면서 중복이라 지워도 된다고 판정해 둔 목록이 있었다. 각 항목에는 저장소에 추적되고 원격에도 반영돼 있다고 적혀 있었다. 지우는 것은 되돌릴 수 없기 때문에 그 기록을 그대로 믿지 않고 다시 확인했다.
Table of contents
Open Table of contents
안에 있는 것과 추적되는 것
작업 트리 안에 파일이 있으면 저장소에 들어 있는 것처럼 보이지만 그것이 추적 대상인지는 별개의 문제다.
.gitignore 에 걸리면 트리 안에 있어도 이력에는 들어가지 않는다. 확인해 보니 목록에 올라 있던 것 일부가 정확히 그 상태였다. 어느 상위 폴더가 통째로 .gitignore 에 들어 있어서 그 아래에 있는 것 전부가 제외돼 있었고 그렇게 제외된 폴더 안의 파일은 ! 규칙으로도 되살릴 수 없다.
추측하지 않고 물어봤다
무시 규칙을 눈으로 읽어서 판단해 보려다가 도중에 그만뒀다. 규칙이 폴더마다의 .gitignore 와 .git/info/exclude 와 core.excludesFile 에 나뉘어 있고 그 사이에 우선순위까지 있어서 읽어서 판정하면 틀린다.
대신 git check-ignore -v 로 파일마다 어느 규칙에 걸렸는지 직접 물어봤다. 추적 목록에 들어 있는지는 git ls-files 로 조회해서 확인했다. 규칙을 해석하는 대신 결과를 도구에 직접 물어보는 쪽이 확실했다.
내용 동일성과 백업 존재
중복이라는 그 판정은 내용이 같다는 것과 다른 곳에 백업이 남아 있다는 서로 다른 두 가지를 함께 뜻하고 있었다.
이 둘은 서로 별개의 항목이므로 각각 따로 확인해야 했다. 내용이 같더라도 두 곳이 다 같은 디스크에 있으면 그 디스크가 죽을 때 함께 사라진다. 중복이라는 한 단어가 안전하다는 뜻으로 읽히는 것 자체가 위험했다.
추적됨과 원격 반영
추적되고 있다는 것도 원격에 올라갔다는 뜻은 아니어서 로컬에만 커밋된 상태라면 그 디스크가 죽을 때 함께 없어진다.
목록에는 원격 반영이라고 적혀 있었지만 git log --branches --not --remotes 로 확인해 보니 일부는 안 올라가 있는 상태였다. 기록을 쓴 시점 이후에 새 커밋이 더 생겨난 경우들이었다. 기록은 그것이 쓰인 시점의 사실이지 지금의 사실이 아니었다.
판단 기준 — 확인 항목을 셋으로
정리하면서 지우기 전에 확인해야 할 것을 셋으로 나눠 두었다. git ls-files 에 드는지와 git log --branches --not --remotes 가 비는지와 다른 물리적 자리에 사본이 있는지다.
이 셋이 전부 참일 때만 지우는 것으로 삭제 기준을 정했다. 그리고 이 확인은 목록을 만들 때가 아니라 실제로 삭제하기 직전에 다시 한다. 되돌릴 수 없는 작업 앞에서는 기록이 아니라 그 시점의 실측이 근거여야 했다.
정리
- 작업 트리 안에 있다는 것이
git ls-files에 든다는 뜻은 아니다 .gitignore가 상위 폴더를 제외하면 그 안은!로도 못 되살린다- 규칙을 해석하지 말고
git check-ignore에 물어본다 - 내용 동일성과 백업 존재는 별개 항목이다
- 두 곳이 다 같은 디스크면 중복이어도 안전하지 않다
- 추적됨과 원격 반영도 별개다
- 기록은 쓰인 시점의 사실이다
- 되돌릴 수 없는 작업은 직전에 다시 확인한다