Watch at Ease세상을 읽고, 일상의 답을 찾다.

기술 · 실용 가이드

git stash pop 실패? 정리 전에 부분 복원부터 확인하세요

같은 이름의 파일이 미추적 파일 복원을 막아도 추적 파일의 변경은 이미 적용됐을 수 있습니다. 두 버전을 보존하고 정확한 stash를 확인한 뒤 복원 결과를 비교해 삭제를 결정하세요.

부분 복원 일러스트
자체 제작 일러스트: 추적 변경은 이미 적용됐을 수 있으며 로컬 충돌 파일과 stash를 따로 확인합니다. Watch at Ease

stash 복원 오류만으로 작업 트리가 그대로라고 판단할 수는 없습니다. 먼저 현재 상태를 보존하고 실패한 작업이 어디까지 진행됐는지 확인하세요. 비교하기 전까지 로컬 파일과 stash의 같은 이름 파일을 서로 다른 버전으로 취급해야 합니다.

1. 재시도 전에 증거를 보존하세요

전체 오류, 명령, Git 버전, 브랜치, stash 목록과 현재 상태를 저장하세요. git status --short --untracked-files=all --ignored와 스테이징 전후의 차이를 모두 확인합니다. 무시 파일도 표시해야 합니다. 일반 상태가 깨끗해 보여도 무시되는 같은 이름 파일이 없다는 뜻은 아닙니다. 경로를 바꾸기 전에 중요한 로컬 파일과 완전한 Git 데이터를 독립적으로 보존하세요. 일반적인 clone이나 diff 내보내기가 모든 stash와 미추적 파일을 자동으로 보존하지는 않습니다.

Git 2.51.1을 사용하는 독립적인 모의 저장소에서 추적 파일 변경과 미추적 파일을 -u로 저장한 다음, 미추적 파일과 같은 경로에 다른 로컬 내용을 만들었습니다. pop은 종료 코드 1을 반환했지만 추적 파일 변경은 적용됐고, 로컬 충돌 파일과 원래 stash는 유지됐습니다. 부분 복원이 가능하다는 사례이며 사용자의 저장소를 진단한 결과나 모든 버전에 대한 보장은 아닙니다.

2. stash를 식별하고 충돌을 분류하세요

git stash list에서 대상 항목을 선택하고, 선택한 stash 참조에 ^{commit} 접미사를 붙여 git rev-parse --verify로 전체 객체 ID를 기록하세요. 실제 선택한 참조를 사용하고 가장 최신 항목이 대상이라고 가정하지 마세요. 기록한 ID를 git stash show --include-untracked --patch로 살펴보고, 지원되는 버전에서는 --only-untracked --name-only도 사용할 수 있습니다. 원래 항목은 남겨 두세요. 이후 작업으로 순번이 바뀔 수 있습니다.

오류에 나온 각 경로를 현재 인덱스와 파일에 대조하세요. 지금 미추적 파일인지, 무시 파일인지, 현재 브랜치가 추적하는 파일인지 확인합니다. stash를 만들 때 포함됐는지도 확인하세요. 경로의 분류가 바뀌었을 수 있습니다. Atlassian은 저장된 미추적 내용이 stash 구조 안에 별도로 저장된다고 설명하지만 모든 stash에 그 부분이 있는 것은 아닙니다. 실제 저장 내용을 확인하기 전에 일괄적인 세 번째 부모 명령이나 덮어쓰기 방법을 적용하지 마세요.

3. 통제된 위치에서 복원하고 비교하세요

독립적인 보존을 확인한 뒤 중요한 로컬 충돌 파일을 삭제하지 말고 복원 경로 밖의 명확히 표시된 위치로 옮기세요. stash를 다시 적용하기 전에 이미 적용된 추적 파일 변경을 고려해야 합니다. 충돌 파일을 옮기는 것만으로 부분 복원이 되돌려지지는 않습니다. 작업 트리가 불확실하면 관련 Git 객체가 완전히 들어 있고 깨끗한 체크아웃이 준비된 독립 저장소 사본에서 복원하고 원본은 그대로 두세요.

git stash branch는 stash의 원래 기준점에서 작업을 재구성할 수 있어 현재 브랜치가 진행된 경우 도움이 됩니다. 설치된 버전의 문서를 따르고 준비한 사본에 별도의 복원 브랜치를 사용하세요. 체크아웃이 깨끗하지 않으면 작업이 막힐 수 있습니다. stash@{n} 이름으로 복원에 성공하면 해당 항목이 삭제될 수 있으므로 먼저 원래 저장소와 정확한 식별 정보를 보존하세요. 복원 파일을 보존한 로컬 사본 및 이미 적용된 추적 파일 차이와 각각 비교한 뒤 의도적으로 통합하세요.

4. 삭제는 별도로 검증하세요

필요한 추적·미추적·무시 내용을 확인하고 스테이징 상태가 중요하면 그것도 검사하세요. 예정된 빌드나 테스트를 실행하고 각 보존 버전의 위치와 채택한 차이를 기록합니다. 적용 성공이 원하는 모든 파일이 처음부터 저장됐다는 증거는 아닙니다. apply는 stash를 유지하므로 항목이 남아 있다고 아무것도 복원되지 않은 것은 아닙니다.

복원을 검증한 뒤 현재 이름이 기록한 객체 ID와 일치하는 항목만 삭제하세요. 광범위한 git clean -xfd나 강제 체크아웃을 첫 대응으로 사용하면 비교에 필요한 내용을 지울 수 있습니다. 범위를 지정한 clean 드라이런은 후보를 보여 줄 뿐 백업하지 않습니다. 필요한 버전을 찾지 못하거나 부분 복원 결과를 설명할 수 없다면 증거와 stash를 유지하고 복원이 끝났다고 판단하지 마세요.

복원 검증 일러스트
자체 제작 일러스트: 보존, 비교, 결과 검증을 마친 뒤 삭제를 판단합니다. Watch at Ease