로그인 화면을 고치던 중 급한 오류를 먼저 확인해야 한다고 가정해 보겠습니다. 아직 커밋할 단계는 아니지만 다른 브랜치로 이동하려면 현재 수정을 잠시 치워야 합니다. 이때 git stash로 변경을 저장하고, 급한 일을 마친 뒤 다시 적용할 수 있습니다. 다만 새 파일이 빠지거나, 복원 중 충돌이 생기는 경우까지 알아야 작업을 잃지 않고 사용할 수 있습니다.

stash에 들어가는 것부터 구분합니다
Git의 작업 폴더는 실제 파일을 편집하는 곳이고, 인덱스는 git add로 다음 커밋에 포함할 내용을 올려 둔 영역입니다. 기본 git stash push는 추적 중인 파일의 작업 폴더 변경과 인덱스 상태를 저장합니다. 추적하지 않는 새 파일과 무시된 파일은 기본 대상이 아닙니다.
| 파일 상태 | 기본 push | 추가로 알아둘 점 |
| 기존 추적 파일 수정·삭제 | 포함 | 아직 git add 하지 않은 수정도 포함 |
| git add로 올린 변경 | 포함 | 복원 시 staging 상태까지 되살리려면 --index 검토 |
| 한 번도 추적하지 않은 새 파일 | 제외 | -u로 포함 가능 |
| .gitignore 등으로 무시한 파일 | 제외 | -a로 포함 가능하지만 먼저 범위 확인 |
‘git add 하지 않은 파일은 전부 빠진다’는 설명은 정확하지 않습니다. 이미 추적 중인 파일의 수정인지, 아직 추적되지 않는 새 파일인지가 차이입니다. 예를 들어 기존 src/login.js 수정은 기본 stash에 들어가지만 새로 만든 notes.txt는 기본적으로 남습니다.
1. 저장 전에 현재 상태를 확인합니다
git status --short
git diff
git diff --cached
git diff는 아직 staging하지 않은 변경, git diff --cached는 staging한 변경을 확인할 때 씁니다. git status --short에서 ??가 붙은 파일은 추적되지 않는 파일입니다. 내용이 중요한 새 파일인지, 잠깐 생성된 파일인지 확인한 뒤 포함 여부를 정하세요.
아래는 상황을 설명하기 위한 출력 예시입니다. 실제 경로와 표시 위치는 자신의 저장소 상태에 따라 다릅니다.
M src/login.js
?? notes.txt
2. 메시지를 붙여 저장하고 결과를 확인합니다
기존 파일 수정만 치우려면 다음처럼 실행합니다.
git stash push -m "로그인 화면 문구 수정 중"
git stash list
git status --short
새 파일 notes.txt도 함께 치우려는 상황이라면 위 push 대신 -u를 붙입니다. 아래 두 push 예제는 선택지이며, 그대로 연속 실행할 필요가 없습니다.
git stash push -u -m "로그인 문구와 작업 메모 임시 보관"
저장 후에는 목록에 새 항목이 생겼는지, 작업 폴더에 남아야 할 것만 남았는지 확인합니다. 출력에 No local changes to save가 나왔다면 새 stash가 만들어진 것이 아닙니다. 이 상태에서 가장 최근 항목을 무심코 꺼내면 이전에 저장한 다른 작업을 적용할 수 있습니다.
-a는 무시한 파일까지 포함합니다. 빌드 산출물이나 큰 캐시, 로컬 설정까지 대상이 될 수 있으므로 폴더를 깨끗하게 만들겠다는 이유만으로 기본 사용하지 마세요. 필요한 변경만 저장할 때는 경로를 지정할 수도 있습니다.
git stash push -m "로그인 파일만 임시 보관" -- src/login.js

3. 꺼내기 전에 목록과 패치를 읽습니다
git stash list
git stash show --stat 'stash@{0}'
git stash show -p -u 'stash@{0}'
가장 최근 항목은 stash@{0}, 그 이전 항목은 stash@{1}입니다. --stat로 파일별 변경 규모를 보고, -p로 실제 수정 내용을 확인합니다. show의 -u는 저장된 추적되지 않는 파일도 표시하는 옵션입니다. 저장 시 빠뜨린 새 파일을 나중에 추가해 주는 옵션은 아닙니다.
예제에서는 중괄호가 있는 참조를 셸에서 안전하게 전달하기 위해 작은따옴표로 감쌌습니다. 새 stash를 추가하거나 기존 것을 삭제하면 번호가 달라질 수 있으므로, 번호만 외워 두지 말고 메시지와 내용을 함께 확인하세요.
4. 처음에는 apply로 복원한 뒤 확인합니다
급한 작업을 마치고 원래 작업을 이어갈 브랜치로 돌아온 뒤 git status를 확인합니다. 현재 작업 폴더에 다른 수정이 섞여 있다면 먼저 그 변경을 어떻게 보존할지 결정하세요. 아래는 현재 브랜치에 저장한 변경을 적용하는 명령입니다.
git stash apply 'stash@{0}'
git status
git diff
git diff --cached
apply는 변경을 적용해도 stash 항목을 남깁니다. 복원된 파일과 필요한 테스트를 확인한 뒤 목록을 다시 보고, 더 이상 필요 없는 항목을 삭제하면 됩니다. staging 상태까지 복원을 시도하려면 git stash apply --index 'stash@{0}'를 사용할 수 있습니다. 다만 충돌이 있으면 인덱스 복원이 실패할 수 있습니다.
| 명령 | 작업 폴더에 적용 | stash 목록 |
| apply | 적용 시도 | 남겨 둠 |
| pop | 적용 시도 | 적용 성공 시 제거, 충돌 시 유지 |
| drop | 적용하지 않음 | 지정 항목 제거 |
매번 확인 후 항목을 지우는 일이 익숙해졌다면 git stash pop으로 복원과 제거를 한 번에 할 수 있습니다. 그러나 pop이 충돌하면 항목은 목록에 남습니다. 오류 메시지가 나왔다는 이유로 같은 pop을 반복하지 마세요.
충돌이 발생했을 때 처리하는 순서
stash를 저장한 뒤 같은 줄이 다른 커밋에서 바뀌면 복원 중 충돌할 수 있습니다. 이때는 ‘보관한 변경이 사라졌다’고 단정하지 말고, 현재 파일과 stash 목록을 먼저 확인합니다.
- git status로 충돌한 파일을 확인합니다.
- 파일의 충돌 표시를 읽고 현재 코드와 보관한 변경 중 필요한 내용을 직접 정리합니다.
- 충돌 표시를 제거한 파일을 git add로 올려 해결 상태를 기록합니다.
- git diff --cached와 관련 테스트로 최종 내용을 확인합니다.
- stash를 계속 보관할지 결정합니다. 지우려면 list와 show로 대상을 다시 확인한 뒤 drop합니다.
stash 충돌 해결 자체에 git merge --continue가 필요한 것은 아닙니다. 복원된 변경은 자신의 작업 흐름에 맞춰 이어서 수정하거나 커밋하면 됩니다. 충돌을 없애려고 git reset --hard부터 실행하면 현재의 미커밋 작업을 잃을 수 있으므로, 무엇을 버리는지 확인하기 전에는 사용하지 않습니다.
오래된 stash라면 새 브랜치에서 복원할 수 있습니다
현재 브랜치가 많이 바뀌어 복원이 어렵다면, 작업 폴더의 다른 변경을 먼저 보존한 뒤 다음 방법을 검토합니다.
git stash branch resume-login 'stash@{0}'
이 명령은 stash를 만들었던 커밋에서 새 브랜치를 만들고 변경을 적용합니다. 지정한 stash 참조를 성공적으로 적용하면 목록에서 해당 항목도 제거합니다. 현재 브랜치에서 반복해서 충돌을 해결하기보다 원래 출발점에서 작업을 정리하는 데 유용합니다.
stash, 커밋, worktree 중 무엇을 고를까
- 잠깐 다른 일을 보고 바로 복귀: stash가 간단합니다.
- 오래 보존하거나 다른 사람에게 전달: 별도 브랜치에 커밋해 작업 이력을 남기는 편이 관리하기 쉽습니다.
- 두 브랜치의 코드를 동시에 열어 비교: git worktree로 작업 폴더를 나누는 방법이 맞습니다.
stash가 생겼다고 원격 저장소에 백업된 것은 아닙니다. 일반적인 브랜치 push만으로 stash 목록까지 공유되지는 않습니다. 또한 git stash clear는 전체 목록을 제거하므로 일상적인 복원 명령과 섞어서 실행하지 마세요.
처음에는 ‘status로 범위 확인 → 메시지를 붙여 push → list와 show로 검토 → apply → 파일 확인’까지만 익히면 됩니다. 작업이 정상적으로 돌아온 것을 확인한 뒤에 보관 항목을 정리하세요.
공식 문서 확인: 2026년 9월 18일. 명령은 설명용이며, 파일 경로와 브랜치 이름은 자신의 저장소에 맞춰 사용합니다.
출처: Git stash 공식 문서 · Pro Git: Stashing and Cleaning · git worktree 사용법
'개발 문제 해결' 카테고리의 다른 글
| 앱 날짜가 하루 달라 보일 때: 저장 시각과 표시 시간대 구분하기 (0) | 2026.09.23 |
|---|---|
| HTTP 429가 보일 때: Retry-After를 읽고 요청 간격 정하기 (0) | 2026.09.23 |
| Git worktree 사용법: 작업 중인 코드를 그대로 두고 다른 브랜치 열기 (0) | 2026.09.18 |
| MySQL EXPLAIN 보는 법: type·key·rows 읽는 순서 (0) | 2026.09.12 |
| Docker 로그 확인: 최근 100줄·시간 범위·Compose 조회 (0) | 2026.09.12 |
댓글