git worktree에서 다른 작업의 stash가 보일 때 안전하게 되돌리는 순서

메타디스크립션: linked worktree끼리 stash 목록이 공유되는 이유를 확인하고, 다른 작업의 최신 stash를 잘못 pop하지 않도록 list·show·apply·drop 순서로 되돌리는 방법을 설명한다.

git worktree로 폴더를 나눠도 stash 목록은 worktree마다 따로 생기지 않습니다. 같은 저장소의 linked worktree는 하나의 refs/stash 스택을 봅니다. 따라서 인수 없이 git stash pop을 실행하기 전에 목록과 patch를 확인하고, 적용할 stash@{n}을 직접 지정하세요.

git stash list
git stash show --stat 'stash@{1}'
git stash show -p 'stash@{1}'

내 변경이 맞다면 바로 지우는 pop보다 먼저 apply로 적용합니다.

git status --short
git stash apply 'stash@{1}'
git status --short

적용 결과와 파일 내용을 확인한 뒤에만 해당 항목을 지웁니다.

git stash list --format='%gd %H'
# 기록한 commit과 같은 행의 현재 stash@{n}을 확인
git stash drop '현재-확인한-stash@{n}'

새 stash가 추가되면 번호가 밀립니다. 적용 전에 적은 commit과 삭제 직전 목록의 commit이 다르면 drop하지 말고 중단하세요. 동시에 다른 작업이 stash를 만드는 환경이면 즉시 정리하지 말고, 해당 작업이 멈춘 뒤 commit을 다시 대조해 삭제하는 편이 안전합니다.

왜 다른 worktree에서 만든 stash가 같이 보일까?

worktree마다 작업 폴더와 체크아웃한 HEAD는 따로입니다. 하지만 stash의 최신 항목은 저장소의 refs/stash에 저장되고, 이전 항목은 그 reflog에 쌓입니다. 공식 문서에서 stash@{0}은 가장 최근 항목, stash@{1}은 그전 항목입니다.

worktree 폴더 자체를 지우려는 상황이면 stash 확인과 폴더 제거를 섞지 마세요. 먼저 수정·미추적 파일이 남은 worktree를 지우기 전 보존하는 순서로 현재 폴더의 변경을 따로 확인하면 두 문제를 나눠서 판단할 수 있습니다.

Git 2.38.1의 비민감 로컬 저장소에서 기본 worktree와 second worktree를 만든 뒤 서로 다른 변경을 stash했습니다. 두 폴더에서 목록을 열었을 때 모두 다음처럼 같았습니다.

stash@{0}: On second: second-worktree
stash@{1}: On i: main-worktree

두 폴더의 stash@{0} commit도 같았습니다. 지금 있는 폴더가 아니라 저장소 전체에서 마지막으로 생성된 stash가 0번이 된다는 뜻입니다.

stash를 만들 때부터 작업 이름을 남긴다

stash를 새로 만들 수 있는 상황이라면 어떤 작업인지 메시지를 붙입니다.

git stash push -m "login-error-copy-before-test"

git stash list의 On 브랜치: 메시지는 후보를 좁히는 데 도움이 됩니다. 다만 같은 메시지를 다시 쓸 수 있으므로 메시지만 보고 바로 pop하지 말고 show -p로 파일과 변경 줄을 확인하세요.

이미 어떤 항목인지 헷갈리면 list와 show만 실행한다

다음 명령은 stash를 적용하거나 지우지 않습니다.

git stash list --date=local
git stash show --name-only 'stash@{0}'
git stash show -p 'stash@{0}'

찾는 변경이 0번이 아니라면 1, 2처럼 정확한 번호를 넣어 다시 봅니다. 번호는 새 stash가 생길 때 밀릴 수 있으므로, 확인과 적용 사이에 다른 작업자가 stash를 추가할 수 있는 환경에서는 항목의 commit도 함께 기록합니다.

git rev-parse 'stash@{1}'

pop보다 apply를 먼저 쓰는 이유

git stash pop은 항목을 적용한 뒤 성공하면 목록에서 제거합니다. 반면 apply는 적용해도 stash를 남깁니다. 적용 대상이 맞는지 확인해야 하는 상황에서는 원본 항목을 남겨 둔 채 파일 결과를 검사할 수 있습니다.

git stash apply 'stash@{1}'
git diff
git status --short

충돌이 나면 계속 명령을 반복하지 말고 git status에서 충돌 파일을 확인합니다. 현재 worktree에 있던 변경과 stash 변경이 겹칠 수 있으므로, 자동으로 안전하게 합쳐진다고 가정하면 안 됩니다.

충돌을 바로 판단하지 못하면 stash를 drop하지 말고 중단합니다. git stash apply에는 독립적인 --abort 명령이 없습니다. 기존 변경이 있는 폴더에서 reset --hard나 checkout -- .로 일괄 복구하지 마세요. 먼저 git status --short를 저장하고 충돌 파일별로 현재 변경과 stash 변경을 구분해 보존합니다.

apply가 성공하면 git stash list에 같은 commit이 그대로 남습니다. stash -u로 미추적 파일까지 담았다면 git diff만으로는 내용을 못 봅니다. git status --short에 ??로 표시된 파일을 직접 열어 필요한 내용인지 확인하세요.

적용 결과가 맞고 필요한 변경이 모두 남은 것을 확인한 뒤 drop을 실행합니다. 여러 사람이 같은 로컬 저장소의 linked worktree를 함께 쓰거나 자동화가 stash를 만들 수 있다면, 확인 직전에 stash list와 commit을 다시 대조하세요.

여러 worktree 경로를 스크립트에서 처리하며 stash와 연결해 자동화한다면, 기본 목록을 공백으로 잘라 읽지 말고 git worktree list –porcelain으로 경로를 안전하게 파싱하는 방법을 함께 확인하세요.

worktree를 지워도 stash가 자동으로 사라지는 것은 아니다

stash는 worktree 폴더 자체가 아니라 저장소의 공용 참조에 들어갑니다. 따라서 git worktree remove로 한 폴더를 제거해도 그 작업에서 만든 stash를 자동으로 정리했다고 단정하면 안 됩니다. 목록과 patch를 확인한 뒤 보존하거나 명시적으로 삭제합니다.

입력부터 결과까지 한 번에 확인하기

순서는 현재 변경 확인, stash 식별, 비파괴적 적용, 결과 검증, 명시적 삭제의 5단계다.

1. git status --short로 현재 작업 폴더의 변경을 확인한다.
2. git stash list 후 show -p로 적용할 항목을 식별한다.
3. git rev-parse 'stash@{n}'의 commit을 기록한 뒤 apply로 항목을 남겨 둔 채 적용한다.
4. git diff, git status --short, 미추적 파일 내용으로 결과를 확인한다.
5. 삭제 직전 목록에서 기록한 commit의 현재 stash@{n}을 다시 찾아, 일치할 때만 drop한다.

# 1. 현재 작업 폴더의 미커밋 변경 확인
git status --short

# 2. 저장소 전체 stash 후보 확인
git stash list --date=local

# 3. 적용할 항목의 파일과 patch 확인
git stash show --name-only 'stash@{1}'
git stash show -p 'stash@{1}'
git rev-parse 'stash@{1}'

# 4. 항목을 남긴 채 적용
git stash apply 'stash@{1}'

# 5. 결과 확인 뒤 commit을 다시 대조해 현재 번호로만 삭제
git status --short
git diff
git stash list --format='%gd %H'
git stash drop '현재-확인한-stash@{n}'

핵심은 worktree 이름으로 stash 소유권을 추정하지 않는 것입니다. list에서 후보를 찾고, show로 내용을 보고, apply 뒤 결과를 확인한 다음 drop을 분리하면 다른 작업의 임시 변경을 잘못 꺼낼 위험을 줄일 수 있습니다.

자주 묻는 질문

stash@{0}은 현재 worktree에서 만든 항목인가?

아니다. 같은 저장소에서 가장 최근에 만든 stash다. 현재 worktree와 다른 곳에서 만들었을 수 있으므로 show -p로 내용을 확인한다.

apply가 성공하면 바로 drop해도 되나?

바로 지우지 않는다. git status --short와 git diff로 파일·변경 줄을 확인한 뒤, 원한 항목이 맞을 때만 같은 stash를 drop한다.

apply 중 충돌이 나면 어떻게 하나?

stash를 drop하지 말고 중단한다. git status --short로 충돌 파일을 기록하고, 현재 변경과 stash 변경을 파일별로 구분한 뒤 해결한다. 판단이 어렵다면 전체 삭제 명령을 쓰지 않고 원본 stash를 보존한다.

검증 기준

• 마지막 업데이트일: 2026-09-23
• 확인 환경: macOS 비민감 임시 저장소, Git 2.38.1, 기본 worktree와 linked worktree 1개
• 직접 확인: 같은 저장소에 연결된 두 worktree에서 동일한 stash 목록과 동일한 stash@{0} commit 확인
• 주요 근거: Git stash 공식 문서, linked worktree에서 다른 작업의 stash를 pop한 공개 사례
• 공개 질문 근거: linked worktree에서 다른 작업의 stash를 pop한 사례
• 한계: 정확 월간 검색량과 seoin.dev 독자의 직접 피드백은 미확인이다. GUI별 stash 표시와 모든 Git 버전의 문구를 확인한 결과는 아니다.