git pull --rebase --autostash 충돌 복구, 오늘 다시 확인한 안전한 순서

배포 직전이라 원격 브랜치 최신 내용을 먼저 당겨오려는데, 손봐 두었던 설정 파일 한 줄 때문에 git pull --rebase 가 바로 멈추는 순간이 있습니다. 급할수록 stash 를 수동으로 만들었다가 다시 꺼내는 과정에서 더 꼬이기 쉽고, 작업트리 상태를 놓치면 되돌리기도 어려워집니다.

이번 글은 로컬 수정이 남아 있는 상태에서 pull 이 막히는 상황을 출발점으로 잡습니다. 2026년 7월 29일 기준 Git 공식 문서를 다시 확인한 뒤, --autostash 로 안전하게 우회하는 방법과 실패했을 때 되돌리는 순서까지 한 번에 정리합니다.

문제가 시작되는 지점은 생각보다 단순합니다

공식 git pull 문서는 pull 이 먼저 fetch 를 수행한 다음 현재 브랜치에 통합한다고 설명합니다. 여기서 --rebase 를 선택하면 merge 대신 rebase 가 수행되는데, 로컬 작업트리에 정리되지 않은 수정이 남아 있으면 아예 시작 단계에서 중단될 수 있습니다.

실무에서는 이 상황이 흔합니다. .env, docker-compose.yml, appsettings.json 같은 파일을 잠깐 손본 뒤 아직 커밋하지 않았는데, 동료가 올린 변경을 먼저 받아야 할 때가 대표적입니다. 수정량은 작아 보여도 rebase 는 현재 작업트리가 깨끗하다는 전제를 강하게 요구합니다.

재현은 작은 저장소 하나면 충분합니다

아래 명령은 문제를 일부러 재현하는 최소 예시입니다. 핵심은 브랜치를 하나 만든 뒤 로컬 파일을 더럽혀 두고 git pull --rebase 를 실행해 보는 것입니다.

mkdir /tmp/git-autostash-demo
cd /tmp/git-autostash-demo
git init
printf 'base\n' > app.txt
git add app.txt
git commit -m "base"
git switch -c feature
printf 'local-change\n' >> app.txt
git pull --rebase origin main

원격이 실제로 연결된 저장소라면 여기서 비슷한 오류를 보게 됩니다. 메시지 표현은 환경마다 조금씩 달라도, 요지는 작업트리가 지저분해서 rebase 기반 pull 을 바로 진행할 수 없다는 것입니다.

원인은 rebase 가 커밋 재적용 작업이기 때문입니다

공식 git rebase 문서는 rebase 가 현재 브랜치의 커밋을 다시 재적용하는 과정이라고 설명합니다. 이 과정은 작업트리와 인덱스가 예측 가능한 상태여야 안전합니다. 아직 정리되지 않은 수정이 끼어 있으면, 어떤 변경이 로컬 임시 수정이고 어떤 변경이 재적용된 커밋 결과인지 경계가 흐려집니다.

그래서 Git 은 시작 전에 멈추고 선택을 요구합니다. 직접 git stash push 로 치워 두든지, 커밋하든지, 아니면 --autostash 같은 보조 옵션으로 임시 보관을 자동화하든지 셋 중 하나를 택하라는 뜻입니다.

가장 짧은 해결은 autostash 를 명시하는 것입니다

git pull 문서와 git rebase 문서 모두 --autostash 흐름을 현재도 설명합니다. 작업 시작 전에 임시 stash 를 만들고, 작업이 끝나면 다시 적용합니다. 같은 문서는 마지막 재적용 시점에는 추가 충돌이 생길 수 있다고 경고하지만, 단순한 환경 파일 수정처럼 범위가 좁은 경우에는 가장 실용적인 우회책입니다.

git pull --rebase --autostash origin main

반복해서 같은 패턴을 쓰는 저장소라면 설정으로 켤 수도 있습니다.

git config pull.rebase true
git config rebase.autoStash true

이렇게 두면 이후 git pull 이 기본적으로 rebase 를 사용하고, 필요한 경우 임시 stash 도 자동으로 생성합니다. 다만 팀이 merge 기반 전략을 쓰는 저장소라면 전역 설정 대신 저장소 단위 설정으로 제한하는 편이 안전합니다.

확인은 성공 메시지보다 상태 점검이 더 중요합니다

명령이 끝났다고 바로 닫지 말고 git status 를 먼저 확인합니다. 가장 이상적인 결과는 working tree clean 이고, 로컬 수정이 원래대로 복원되어야 한다면 변경 파일이 다시 보이는지도 같이 확인해야 합니다.

git status
git status --porcelain
git stash list
git diff --stat

stash list 에 임시 항목이 남아 있지 않다면 자동 보관이 정상적으로 마무리된 것입니다. 반대로 항목이 남아 있다면 재적용 도중 충돌이 있었거나, 사용자가 중간에 흐름을 끊었을 가능성이 있습니다. 이때는 남은 stash 이름을 확인한 뒤 필요한 것만 git stash apply 또는 git stash pop 으로 꺼내면 됩니다.

충돌이 났을 때는 되돌리기 순서를 짧게 가져가야 합니다

공식 git rebase 문서는 충돌 처리 대신 원래 상태로 돌아가려면 git rebase --abort 를 사용하라고 안내합니다. 이미 충돌 파일을 건드리기 시작했다면, 상태를 더 복잡하게 만들기 전에 먼저 abort 로 기준점을 되찾는 편이 낫습니다.

git rebase --abort
git stash list
git stash show -p stash@{0}

abort 이후에는 pull 이전 상태로 돌아가므로, 정말 필요한 수정인지 다시 판단할 수 있습니다. 임시로 숨겨 둔 변경이 중요하다면 별도 브랜치로 빼서 커밋하고, 중요하지 않다면 버린 뒤 다시 pull 을 시도하는 편이 오히려 빠를 때가 많습니다.

실무에서는 옵션보다 규칙을 같이 정하는 편이 덜 사고 납니다

--autostash 는 편리하지만 만능은 아닙니다. 긴급 핫픽스 브랜치에서 로컬 변경 범위가 넓거나, 잠깐 바꾼 파일이 테스트를 깨뜨릴 가능성이 있으면 임시 stash 복원 이후에도 다시 확인해야 합니다. 결국 중요한 것은 pull 전에 작업트리를 보는 습관과, abort 지점을 빠르게 선택하는 규칙입니다.

정리하면 2026년 7월 29일 기준으로도 공식 문서가 안내하는 흐름은 변하지 않았습니다. 더러운 작업트리에서 rebase pull 이 막히면 --autostash 로 우회할 수 있고, 충돌이 복잡해지면 git rebase --abort 로 원위치한 뒤 stash 상태를 점검하면 됩니다. 급한 배포일수록 이 두 단계만 기억해도 작업트리를 불필요하게 망가뜨릴 가능성을 크게 줄일 수 있습니다.

---

공식 문서 확인 링크: git-pull, git-rebase, git-stash