Git stash 사용법

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

Git stash 사용법

git stash는 작업 트리와 index의 현재 상태를 잠시 치워 두고 HEAD 기준의 깨끗한 작업 디렉터리로 돌아가고 싶을 때 쓰는 명령이다. 2026년 6월 30일 기준 Git 공식 git-stash 문서를 보면 기본 호출은 git stash push와 같고, 저장된 항목은 refs/stash와 그 reflog에서 관리된다.

실무에서 헷갈리는 지점은 네 가지다. staged 변경만 넣을지, untracked 파일까지 같이 넣을지, 복원할 때 목록에서 제거할지, 충돌이 예상되면 새 브랜치로 푸는 편이 나을지다. 이 글은 최신 Git 문서 기준으로 push, apply, pop, branch와 주요 옵션 선택 기준을 짧게 정리한다.

Git stash는 정확히 무엇을 저장할까?

공식 문서 설명은 단순하다. git stash push는 현재 작업 디렉터리와 index의 로컬 수정 상태를 새 stash entry로 저장한 뒤, 작업 트리와 index를 HEAD에 맞춰 되돌린다. 그래서 임시 저장이 목적이어도 결과적으로는 작업 디렉터리를 비우는 명령으로 이해하는 편이 맞다.

저장된 항목은 기본적으로 stash@{0}, stash@{1} 같은 이름으로 쌓인다. 가장 최근 stash는 refs/stash에 놓이고, 이전 항목은 reflog 문법으로 참조할 수 있으므로 "방금 넣은 것"인지 "어제 넣은 것"인지 구분해서 적용할 수 있다.

어떤 명령을 먼저 외우면 될까?

명령	언제 쓰나	핵심 동작
git stash push	현재 변경을 잠시 치울 때	stash를 만들고 작업 트리와 index를 HEAD에 맞춤
git stash apply	복원은 하되 목록은 남기고 싶을 때	stash를 적용하지만 삭제하지 않음
git stash pop	복원 후 바로 소비하고 싶을 때	적용이 성공하면 목록에서 제거함
git stash branch <name>	현재 브랜치와 충돌이 걱정될 때	stash가 만들어진 시점의 commit에서 새 브랜치를 만들고 적용함

git stash만 단독으로 치면 문서상 git stash push와 동일하다. 반면 git stash save는 deprecated로 표시되어 있고 pathspec을 받을 수 없으므로, 지금 기준으로는 새 문서나 팀 가이드에 save를 기준 명령으로 적는 이유가 거의 없다.

staged 변경만 stash하고 싶다면 어떻게 해야 할까?

이때는 git stash push --staged를 먼저 보면 된다. 공식 문서는 --staged를 "현재 staged 된 변경만 stash한다"라고 설명한다. 즉 index에 올린 파일만 잠시 빼 두고, 아직 add 하지 않은 작업 트리 수정은 그대로 남길 수 있다.

반대로 일부 hunk만 고르고 싶다면 --patch가 맞다. 문서에 따르면 --patch는 interactive hunk 선택 모드이며, 기본적으로 --keep-index를 암시한다. 그래서 "테스트가 통과한 staged 묶음은 남기고, 아직 정리 중인 일부 수정만 치우기" 같은 상황에 더 잘 맞는다.

untracked 파일과 ignored 파일은 기본으로 들어갈까?

기본값은 아니다. 문서 기준으로 --include-untracked 또는 -u를 써야 untracked 파일까지 stash하고 정리할 수 있고, --all 또는 -a를 써야 ignored 파일까지 포함된다. 이 두 옵션은 내부적으로 정리 단계에서 git clean 동작을 동반한다.

선택 기준은 단순하다. 새로 만든 임시 파일까지 같이 치워야 브랜치 전환이나 긴급 hotfix가 가능한 상황이면 -u를, 빌드 산출물이나 캐시 파일까지 포함해 완전히 비우고 싶다면 -a를 본다. 다만 ignored 파일은 의도적으로 보존하는 경우가 많아서, 평소 기본값으로 -a를 습관처럼 쓰는 편은 조심하는 것이 낫다.

apply와 pop는 무엇이 다를까?

문서 정의는 명확하다. pop은 stash를 적용하고, 적용이 성공하면 stash 목록에서 제거한다. apply는 같은 복원 동작을 하지만 목록에서 제거하지 않는다.

중요한 차이는 실패 처리다. 공식 문서는 pop 적용 중 충돌이 나면 stash가 자동으로 제거되지 않는다고 설명한다. 그래서 현재 브랜치 상태와 충돌 가능성이 있거나, 먼저 diff를 확인하고 안전하게 재시도하고 싶다면 apply가 더 보수적인 선택이다.

 

 

충돌이 걱정되면 왜 git stash branch를 볼까?

git stash branch <branchname>는 stash가 처음 만들어졌던 시점의 commit에서 새 브랜치를 만들고, 그 위에 stash를 적용한다. 문서도 현재 브랜치가 많이 달라져서 apply가 충돌을 일으키기 쉬운 경우 이 명령이 유용하다고 설명한다.

즉 원래 작업하던 기반 commit과 현재 브랜치가 많이 벌어졌다면, 지금 브랜치 위에 억지로 올리기보다 stash 생성 시점의 맥락을 복구하는 편이 안전하다. 실무에서는 오래 묵은 stash일수록 apply보다 branch가 덜 위험한 경우가 많다.

stash 내용을 확인할 때는 무엇을 보면 될까?

목록은 git stash list, 상세 차이는 git stash show로 본다. 문서에 따르면 show의 기본 출력은 diffstat이며, -p를 주면 patch 형식으로 볼 수 있다. 또 stash.showStat, stash.showPatch, stash.showIncludeUntracked 설정으로 기본 표시 방식을 바꿀 수 있다.

untracked 파일까지 확인하고 싶다면 git stash show --include-untracked를 쓰면 된다. "무엇을 stash했는지 기억이 흐릿한 상태"에서 바로 pop부터 하는 것보다, 먼저 list와 show -p로 범위를 확인하는 편이 안전하다.

최신 Git 문서에서 같이 볼 만한 기능은 무엇일까?

2026년 6월 29일 갱신된 최신 문서에는 git stash export와 git stash import도 정식 하위 명령으로 나온다. 설명상 export는 지정한 stash들을 일반 fetch/push 메커니즘으로 옮길 수 있는 commit 체인으로 내보내고, import는 그 commit에서 stash 목록으로 다시 들여온다.

이 기능은 대부분의 일상 작업에서 필수는 아니다. 다만 stash를 단순 로컬 임시 보관함이 아니라, 옮기거나 백업해야 하는 특별한 상태로 다뤄야 할 때는 문서상 공식 경로가 있다는 점을 알아 두면 좋다.

자주 헷갈리는 질문

Q. git stash와 git stash push는 다른가?

현재 공식 문서 기준으로 인자 없이 호출한 git stash는 git stash push와 같다. 다만 pathspec을 쓸 때는 오타로 원치 않는 stash를 만들지 않도록 git stash push -- path/to/file처럼 subcommand를 명시하는 편이 더 분명하다.

Q. stash를 적용하면서 staged 상태도 같이 복원할 수 있나?

가능하다. apply와 pop에는 --index 옵션이 있고, 문서는 작업 트리 변경뿐 아니라 index 상태까지 되살리려 시도한다고 설명한다. 다만 충돌이 있으면 이 복원은 실패할 수 있다.

Q. 오래된 stash를 현재 브랜치에 바로 pop해도 될까?

그렇게 단정하기는 어렵다. 공식 문서도 현재 브랜치가 많이 달라진 경우 stash branch를 별도 대안으로 제시한다. 기반 commit이 많이 달라졌다면 새 브랜치에 먼저 복원해 차이를 보는 편이 더 안전하다.

정리

git stash의 판단 기준은 "무엇을 치울지"와 "어디에 다시 올릴지" 두 가지로 나눌 수 있다. staged만 숨길 때는 --staged, 일부 hunk만 치울 때는 --patch, untracked까지 비울 때는 -u, ignored까지 포함할 때는 -a를 보면 된다.

복원 단계에서는 재사용 가능성을 남기려면 apply, 한 번 쓰고 끝내려면 pop, 충돌 위험이 크면 branch가 무난하다. 2026년 6월 30일 기준 Git 공식 문서만 놓고 봐도 stash는 단순 임시 서랍이 아니라, 작업 단위를 안전하게 비우고 다시 붙이는 절차로 이해하는 편이 정확하다.

참고 자료

• Git Documentation: git-stash