Git Stash Pop 충돌(Conflict) 완벽 복구: 임시 저장소 안전 워크플로우
[Troubleshooting] Git Stash Pop 충돌(Conflict) 완벽 복구: 안전 워크플로우
"급한 버그 픽스가 들어와서 현재 작업하던 코드를 git stash로 잠시 짱박아두고 버그를 고친 후 git stash pop을 쳤습니다. 그런데 화면에 무수한 충돌(Conflict) 에러가 뜨더니 제가 며칠 동안 짜놓은 코드가 다 꼬여버리고, 스태시(Stash) 목록에서도 지워져 버렸습니다."
다수의 브랜치를 오가며 바쁘게 개발을 진행하는 실무자들이 겪는 가장 아찔한 코드 유실 위기입니다. Git의 임시 저장소인 Stash는 매우 유용하지만, 그 동작 원리를 모른 채 무심코 명령어를 남발하면 며칠 치 야근이 허공으로 증발하는 대형 사고로 이어집니다.
초보자들은 충돌이 난 파일을 수습하려다 에디터를 끄고, 되돌리기(Ctrl+Z)를 연타하다가 결국 코드를 포기합니다. 본 가이드에서는 pop 명령어에 숨겨진 치명적인 위험성을 해체하고, 충돌 앞에서도 절대 코드가 날아가지 않는 엔터프라이즈급 임시 저장소 안전 워크플로우를 단호하게 제시합니다.
📌 이 글의 핵심 포인트
- 충돌의 원리: 버그 패치 과정에서 내가 수정한 파일과 스태시에 저장해 둔 파일의 라인(Line)이 겹칠 때 발생하는 시공간의 붕괴
- Pop의 함정: 적용(Apply)과 동시에 기록을 삭제(Drop)해버려 복구를 불가능하게 만드는
git stash pop의 폭력성- 무결점 워크플로우:
git stash apply를 통한 원본 보존 전략과 충돌 해결 튜닝
1단계: 핵심 원인 분석 - Pop은 적용이 아니라 '잘라내기'다
Git Stash에 코드를 넣는 것은 임시 금고에 서류를 복사해 두는 것과 같습니다. 그런데 당신이 습관적으로 사용하는 git stash pop 명령어는 사실 두 가지 동작이 하나로 합쳐진 명령어입니다.
1) 금고에서 서류를 꺼내 책상에 올린다 (Apply) + 2) 금고 안의 원본 서류를 불태워버린다 (Drop)
만약 꺼낸 서류가 책상 위의 문서와 겹치지 않으면(정상 병합) 아주 깔끔하게 동작합니다. 하지만 코드가 겹쳐서 병합 충돌(Conflict)이 나버리는 순간 책상은 난장판이 되는데, 금고 안의 원본 서류마저 날아가 버린 최악의 상태에 빠지는 것입니다.
2단계: 완벽한 트러블슈팅 - Apply와 Drop의 철저한 분리
진정한 엔지니어는 절대 코드를 한 번에 삭제하지 않습니다. pop 명령어를 머릿속에서 지워버리고, 오직 적용(Apply)만을 수행하여 원본을 금고에 남겨두는 안전한 아키텍처를 도입하십시오.
# ❌ 최악의 안티 패턴: 적용과 동시에 임시 저장 기록을 파괴함
# 충돌이 나면 복구하기가 매우 까다로워짐
git stash pop
# ✅ 완벽한 안전 워크플로우 1단계: 원본을 유지한 채 코드만 덮어씌움
git stash apply
# (충돌이 발생했다면 VSCode 등의 에디터에서 천천히 코드를 수습하고 git add . 수행)
# ✅ 완벽한 안전 워크플로우 2단계: 충돌 해결 및 테스트가 모두 끝난 후 명시적 삭제
git stash drop
apply를 사용하면 혹시라도 코드를 수습하다가 실수로 파일을 날려 먹어도, 터미널에 git reset --hard를 친 다음 언제든지 git stash apply로 다시 코드를 깔끔하게 불러올 수 있는 무한 루프의 생명줄을 얻게 됩니다.
3단계: 고도화 튜닝 - 특정 Stash 선택하기
임시 저장을 여러 번 하다 보면 금고 안에 서류가 여러 장(stash@{0}, stash@{1}...) 쌓이게 됩니다. 이때 아무 옵션 없이 apply를 치면 가장 최신의 것(0번)만 불러옵니다.
# 현재 금고에 저장된 모든 임시 저장 리스트 확인
git stash list
# 1번(두 번째로 최신) 인덱스에 저장된 코드를 안전하게 불러오기
git stash apply stash@{1}
목록을 확인하고 원하는 인덱스 번호를 핀셋처럼 집어내어 적용하는 것이 버전 관리의 정석입니다.
🙋♂️ 자주 묻는 질문 (FAQ)
Q. 이미 실수로 pop을 써서 충돌이 났고 터미널 창도 꺼버렸는데, 복구할 수 없나요?
A. 다행히 Git 엔진은 바보가 아닙니다. pop을 쳤을 때 충돌(Conflict)이 감지되면, 친절하게도 내부적인 Drop(삭제) 동작을 일시 중단하고 스태시 목록을 살려둡니다. 지금 터미널에 git stash list를 쳐보시면 당신의 코드가 기적처럼 남아있는 것을 확인할 수 있을 것입니다.
💡 핵심 정리 및 마무리
버전 관리 도구의 편리한 명령어 이면에는 데이터 유실이라는 양날의 검이 숨어 있습니다. 단축 명령어(pop)가 주는 달콤한 속도에 취하지 말고, apply와 drop이라는 두 가지 원시 동작(Atomic Action)을 의도적으로 분리하여 통제하십시오. 작은 워크플로우의 변화가 당신의 프로젝트 전체를 재앙으로부터 구원할 튼튼한 방패가 될 것입니다.
댓글
댓글 쓰기