Git 브랜치 전환 전 확인할 것: 저장되지 않은 변경 관리

다른 브랜치를 확인하려는데 수정한 파일이 남아 있으면 먼저 무엇이 어디에 보관되어 있는지 정리해야 합니다. 편집기에서 아직 저장하지 않은 문장, 디스크에는 저장됐지만 커밋하지 않은 코드, 새로 만든 미추적 파일은 보관 방법이 같지 않습니다. 브랜치를 바꾸기 전 상태를 읽으면 중요한 변경을 잊는 일을 줄일 수 있습니다.

아래 main과 feature-note는 설명용 브랜치 이름입니다. 독자의 저장소에 실제로 존재하는 이름으로 바꿔야 하며, 이 글의 명령은 사용자 저장소에 자동 실행되는 절차가 아닙니다. 서브모듈이나 진행 중인 병합이 없는 간단한 저장소를 기준으로 설명하고 실제 오류는 표시 내용을 따로 확인합니다.

한눈에 보는 브랜치 전환과 작업 복원 순서

1. 편집기 저장과 Git 커밋은 다른 단계

편집기 탭에 미저장 표시가 있다면 해당 내용은 아직 디스크의 파일과 다를 수 있습니다. Git으로 변경을 보관하기 전에 남길 내용을 파일에 저장하고 실제 경로를 확인하세요. 다른 이름의 파일이나 다른 프로젝트 폴더에 저장하면 현재 저장소의 상태를 읽어도 그 내용을 찾지 못할 수 있습니다.

디스크에 저장했다고 Git의 커밋에 포함된 것은 아닙니다. Git은 작업 폴더, 커밋할 변경을 모으는 인덱스와 커밋 기록을 구분합니다. “저장 안 된 코드”라는 표현 대신 편집기 미저장인지 Git 미커밋인지 말하면 어떤 작업이 필요한지 명확해집니다.

상태	어디를 확인할까?	보관 전에 할 일
편집기 미저장	탭 표시와 실제 파일 경로	남길 내용을 파일로 저장
수정된 추적 파일	Git 상태와 차이	커밋 또는 임시 보관 범위 결정
새 미추적 파일	상태의 새 파일 목록	보관 대상에 포함할지 결정
무시된 파일	실제 파일과 무시 규칙	필요하면 별도 보관 확인

가상의 개발자가 메모를 편집기에서만 수정하고 Git stash를 만들었다면 그 미저장 문장이 보관됐다고 단정할 수 없습니다. 중요한 내용은 편집기와 디스크를 먼저 맞추고 Git에서 관찰한 범위를 연결해야 합니다. Git 기록이 편집기의 모든 임시 상태를 대신하는 것은 아닙니다.

2. 전환 전 현재 브랜치와 변경 목록 읽기

git status --short --branch
git diff
git diff --cached

상태에서는 현재 브랜치와 변경 파일을 보고, 차이에서는 실제 수정 내용을 읽습니다. 일반적인 비병합 상황의 짧은 상태에서 첫 칸은 인덱스, 두 번째 칸은 작업 폴더의 상태를 나타냅니다. 물음표 두 개는 미추적 파일이며 기본 상태 목록에는 무시된 파일이 보이지 않을 수 있습니다.

가상의 결과에 notes.txt 수정과 new-plan.txt 미추적 표시가 있다면 두 파일을 보관할 계획에 넣을지 결정합니다. 추적된 파일의 차이만 읽으면 새 파일이 빠질 수 있으므로 상태 목록도 함께 봅니다. new-plan.txt의 실제 내용을 읽어 필요한 작업 자료인지 구분하세요.

현재 브랜치 이름과 돌아올 위치를 적어 두는 것도 도움이 됩니다. 두 브랜치의 이름이 비슷하면 잘못된 곳에서 복원을 시작할 수 있습니다. “이전 브랜치로 복귀”라는 막연한 기억보다 실제 이름과 보관 기록을 연결하면 전환 뒤의 판단이 쉬워집니다.

3. 커밋할 변경과 임시 보관할 변경 선택하기

완성된 의미 있는 작업이라면 프로젝트의 관례에 따라 커밋할 수 있습니다. 아직 진행 중이라면 stash로 잠시 보관하는 방법을 검토할 수 있습니다. 이 두 가지 선택은 작업의 완성도와 돌아올 계획에 따라 정하며, 전환을 위해 필요 없는 파일까지 한꺼번에 커밋하지 않습니다.

가상의 notes.txt와 new-plan.txt가 아직 작성 중이라면 어떤 파일을 임시 보관할지 명확히 합니다. 기존 코드의 일부 수정과 새 문서가 같은 작업 묶음인지 읽고 보관 기록에 이름을 붙입니다. 나중에 임시 기록이 여러 개 생겼을 때 설명이 있어야 필요한 항목을 고르기 쉽습니다.

중요한 자료가 Git의 추적 대상에 들어 있지 않다면 그 보관 조건을 별도로 확인합니다. 임시 보관은 현재 저장소에서 다시 적용하는 작업 수단이고 외부 백업이나 모든 편집 상태의 보존을 자동 보장하는 개념으로 사용하지 않습니다. 새 파일과 무시된 파일을 빠뜨리지 않는지가 핵심입니다.

4. 미추적 파일을 포함한 임시 보관 예시

git stash push -u -m "before-switch-demo"
git stash list
git stash show -p -u 'stash@{0}'
git status --short --branch

위 예시는 새 미추적 파일도 포함하도록 -u를 지정한 보관입니다. Git 공식 문서는 stash의 작업 폴더·인덱스 보관, -u의 미추적 파일 포함과 -a의 무시된 파일 포함을 구분합니다. 여기서는 무시된 파일을 포함하는 -a를 기본 예시에 넣지 않으므로 그런 파일까지 저장됐다고 생각하면 안 됩니다.

stash 명령 뒤에는 목록과 차이를 읽어 실제로 어떤 기록이 생겼는지 확인합니다. stash@{0}은 그 시점의 가장 최근 항목을 뜻하므로 새 보관을 더 만들었다면 필요한 항목을 다시 골라야 합니다. PowerShell에서 중괄호가 있는 참조는 예시처럼 따옴표로 감싸 명령에 전달할 수 있습니다.

현재 상태도 다시 읽습니다. 보관하지 않은 파일이나 다른 변경이 남을 수 있기 때문입니다. 가상의 무시된 local-output 폴더가 중요하다면 -u 보관 결과만으로 그 폴더의 내용까지 보존됐다고 기록하지 않습니다. 무엇이 남았는지 확인하고 필요한 파일은 적절한 별도 방법으로 보관합니다.

5. 전환이 거부되면 강제 옵션보다 남은 변경 확인하기

git switch main
git status --short --branch

main이 실제로 존재하고 그 브랜치를 확인하려는 예시입니다. Git 공식 문서에 따르면 전환에 항상 깨끗한 작업 폴더가 필요한 것은 아니지만 로컬 변경 손실을 초래할 전환은 기본적으로 중단됩니다. 미커밋 변경이 있으면 무조건 실패한다거나, 전환만 하면 모두 없어지는 것으로 설명할 수는 없습니다.

거부 문구가 나타나면 해당 파일과 남은 변경을 읽고 보관 범위를 다시 확인합니다. 진행 중인 병합·충돌 같은 다른 조건이 있으면 그것도 따로 다뤄야 합니다. 오류를 없애기 위해 변경을 버리는 옵션을 바로 붙이면 남기려던 작업과 전환 목적이 어긋날 수 있습니다.

전환이 성공한 경우에는 실제 현재 브랜치를 확인합니다. 명령을 입력했다는 사실과 전환된 결과는 나누어 읽어야 합니다. 변경이 남아 있다면 무엇이 남았는지 확인하고, 그 변경이 새 브랜치에서 작업할 내용인지 결정합니다. 예상하지 않은 파일이 보이면 다음 편집 전에 원래 기록과 대조하세요.

6. 원래 브랜치에서 보관한 내용을 다시 적용하기

git switch feature-note
git stash list
git stash apply 'stash@{0}'
git status --short --branch

이 순서는 feature-note로 돌아와 목록에서 확인한 기록을 적용하는 설명용 예입니다. 실제로는 필요한 항목의 설명과 내용을 읽고 참조를 선택해야 합니다. 예시처럼 항상 최신 항목을 쓰면 다른 작업의 보관 내용을 적용할 수 있으므로 이름과 시점을 대조하세요.

공식 문서는 apply가 보관 항목을 목록에 남기는 방식이며 pop은 적용과 목록 제거를 연결한다고 구분합니다. 충돌이 발생할 수 있으므로 적용 성공을 자동 전제로 삼지 않습니다. 이 글의 예시는 원본 임시 기록을 유지한 상태에서 결과를 읽기 위해 apply를 사용합니다.

인덱스에 올려 놓았던 상태까지 다시 만드는 목적은 별도 확인이 필요합니다. 기본 apply와 인덱스 복원 옵션의 차이를 공식 문서에서 읽고 실제 프로젝트에 맞게 선택하세요. 파일 내용이 돌아왔다는 결과와 커밋 준비 상태까지 동일하다는 결과를 같은 것으로 기록하지 않습니다.

7. 충돌이 생기거나 파일이 빠졌을 때 확인하기

적용 중 충돌이 나면 현재 브랜치의 내용과 보관한 수정이 겹쳤는지 확인합니다. 보관한 원래 작업과 새 브랜치의 변경을 비교해 남길 내용을 정해야 합니다. 상태가 불명확한 채 같은 항목을 반복 적용하면 현재 상태가 더 복잡해질 수 있으므로 우선 어떤 결과가 생겼는지 읽습니다.

새 파일이 돌아오지 않았다면 처음 보관 범위에 포함됐는지와 선택한 stash가 맞는지 확인합니다. 편집기에서만 작성했던 자료인지, 무시 규칙에 들어 있었는지도 대조하세요. 여러 원인을 모두 “stash가 지웠다”로 묶기보다 저장 전 기록과 실제 목록을 연결해야 합니다.

복원 후 확인	근거
원래 작업 브랜치인가?	현재 브랜치 표시
필요한 파일이 돌아왔는가?	파일 목록과 실제 내용
새 파일도 있는가?	미추적 파일과 보관 차이
충돌이 남았는가?	상태와 해당 파일의 내용
임시 기록이 유지되는가?	stash 목록

8. 작업을 재개할 때 남길 짧은 기록

가상의 작업 메모는 “feature-note의 문서 수정과 새 계획 파일을 보관, main 확인, 원래 브랜치 복귀, 지정한 항목 적용, 파일 내용 대조”로 정리할 수 있습니다. 이 기록은 수행한 순서를 남기지만 실제 확인하지 않은 복원 성공을 추가하는 용도가 아닙니다.

보관 항목을 정리하기 전에는 필요한 내용이 돌아왔는지와 충돌 해결 여부를 확인합니다. 목록 정리는 원본 임시 기록을 없애는 선택이므로 작업 확인 뒤에 판단합니다. 이 글은 일괄 삭제 명령을 제시하지 않으며 독자의 모든 보관 항목이 불필요하다고 가정하지 않습니다.

전환 전에는 편집기 저장, 상태 읽기와 보관 범위 확인을 하고 전환 뒤에는 실제 브랜치와 복원한 내용을 확인하세요. 각 단계의 근거가 남으면 브랜치를 바꾸는 짧은 작업이 진행 중인 수정을 잃지 않고 이어가는 절차가 됩니다. 그림은 이 흐름을 직접 만든 설명 도해입니다.

공식 출처와 작성 기준

• Git: git-status — Short Format
• Git: git-switch — Description
• Git: git-stash — Commands and options

자료 확인일: 2026-10-07. 실제로 연 공식 자료를 바탕으로 AI가 작성한 설명입니다. 별도 표시한 계산·코드·점검 사례는 설명용이며 사용자 환경을 직접 시험하거나 실측한 결과가 아닙니다. 발행일에는 기능과 자료의 변경 여부를 다시 확인합니다.