숏컷 코드

# 현재 변경을 이름과 함께 임시 저장
git stash push -m "wip: login form validation"

# 다른 브랜치로 이동해 긴급 작업 처리
git switch main

# 원래 브랜치로 돌아와 복원
git switch feature/login
git stash pop

문법

어떤 임시 보관 흐름을 먼저 떠올리면 되나

stash가 필요한 이유 — 커밋하기 애매한 중간 상태가 브랜치 전환을 막는다

Git은 브랜치를 전환하기 전에 작업 트리가 깨끗한(clean) 상태여야 한다고 강제하지는 않지만, 변경 중인 파일이 전환 대상 브랜치와 충돌할 경우 checkout이 거부된다. 커밋하기엔 아직 불완전한 상태에서 긴급히 다른 브랜치로 이동해야 할 때 stash가 이 문제를 해결한다. stash는 현재 작업 트리와 스테이징 영역의 변경을 꺼내 별도 스택에 저장하고 작업 트리를 HEAD 상태로 되돌린다. 내부적으로 stash는 특수 커밋 객체 두 개(WIP 커밋과 index 커밋)로 구현되어 있어, .git/refs/stash가 이를 가리킨다.

pop과 apply의 차이 — 불확실하면 apply가 더 안전하다

git stash pop은 스택에서 최신 stash를 꺼내 적용하고 동시에 stash 목록에서 제거한다. git stash apply는 적용만 하고 stash 목록에는 남긴다. 복원이 제대로 됐는지 확인하기 전에 stash를 잃고 싶지 않다면 apply를 먼저 쓰고 확인 후 git stash drop으로 명시적으로 제거하는 것이 더 안전하다. pop 중 충돌이 발생하면 stash는 제거되지 않고 남아 있다는 점도 알아 두면 혼란을 줄일 수 있다. 스택 구조이므로 특정 stash를 지정할 때는 git stash apply stash@{2} 형태로 인덱스를 명시한다.

# 먼저 확인하면서 복원
git stash apply stash@{0}
git status
git stash drop stash@{0}

# 바로 적용 + 제거
git stash pop

stash는 단기 컨텍스트 전환 도구다 — 장기 보관에는 적합하지 않다

stash는 LIFO(Last In First Out) 스택 구조라 나중에 넣은 것이 먼저 나온다. 여러 개 쌓이면 stash@{0}, stash@{1} 형태로 관리해야 하는데 어느 브랜치의 어떤 작업인지 잊기 쉽다. 실무 경험상 stash에 넣은 채 하루 이상 방치하면 복원 시 컨텍스트를 재구성하는 비용이 생긴다. 한 시간 이상 보관할 작업이라면 git commit -m "wip: 작업 내용"으로 임시 커밋을 남기거나, git switch -c draft/login-form처럼 draft 브랜치를 만들어 커밋해 두는 것이 검색성과 안전성 모두 더 낫다.

untracked 파일을 stash에 포함하려면 옵션이 필요하다 — 기본 동작의 범위를 알아야 한다

git stash push 기본 동작은 추적 중인 파일의 변경(작업 트리 + 스테이징)만 저장하고, untracked 파일은 제외한다. untracked 파일까지 포함하려면 -u 또는 --include-untracked를 추가해야 한다. 새로 생성한 파일이 stash 후에도 작업 트리에 남아 있다면 untracked 파일이 포함되지 않은 것이다. -u 옵션을 쓰면 새 파일도 함께 저장되어 브랜치 전환 후 깨끗한 상태가 된다. .gitignore에 등록된 파일까지 포함하려면 -a (--all) 옵션을 쓴다.

touch draft.md
git stash push -m "wip"

# draft.md는 그대로 남음 (untracked는 기본 stash에 포함되지 않음)

git stash push -u -m "wip with untracked"

선택 기준

주의할 점