Git detached HEAD 해결: 새 브랜치로 작업 보존하고 reflog로 커밋 찾기

태그나 과거 커밋을 확인한 뒤 터미널에 detached HEAD가 표시되어 당황했다면, 먼저 다른 브랜치로 돌아가지 말고 현재 작업을 확인하세요. detached HEAD는 저장소가 망가졌다는 뜻이 아니라 HEAD가 브랜치 이름 대신 특정 커밋을 가리키는 상태입니다. 이 상태에서도 커밋은 가능하지만, 새 커밋을 계속 보관하려면 브랜치 이름을 붙이세요. 이 글은 기존 커밋을 되돌리는 reset·revert가 아니라, 떨어진 HEAD에서 만든 작업을 보존하는 절차입니다.

빠른 결론

• 지금 detached HEAD에 있다면 상태를 확인하고 git switch -c rescue-work로 새 브랜치를 만듭니다.
• 이미 다른 브랜치로 이동했다면 git reflog에서 잃어버린 커밋을 찾은 뒤 이름을 붙입니다.
• 강제 전환·reset --hard·clean으로 정리하지 말고 미커밋 파일부터 별도로 보관합니다.

확인 날짜: 2026년 10월 9일 KST. Git 공식 git-switch·git-checkout·git-reflog 문서 기준이며, 사용자 저장소의 실행 경험은 아니며 버전·상태에 따라 달라집니다. 아래 브랜치 이름은 예시이므로 기존 이름과 겹치지 않게 바꾸세요.

어떤 상태인지 먼저 구분

상황	우선 행동
현재 detached HEAD, 커밋 있음	현재 위치에 새 브랜치 만들기
수정 파일이 아직 미커밋	파일 백업 후 상태 확인, 브랜치 생성과 커밋 보관은 별개
이미 다른 브랜치로 이동	reflog에서 원래 커밋 찾고 rescue 브랜치 연결
기존 브랜치 이름 충돌	-C로 덮어쓰지 말고 새 이름 선택
로컬 변경 때문에 전환 거절	강제 옵션 금지, 변경 내용을 확인하고 보관

1. 현재 작업과 위치 기록하기

1. 작업 중인 저장소 폴더에서 터미널을 엽니다. 다른 프로젝트 폴더에서 명령을 실행하지 않도록 경로를 확인합니다.
2. git status를 실행하여 detached HEAD 여부와 수정·스테이징·추적되지 않은 파일을 확인합니다. 출력에 미커밋 파일이 있으면 필요한 내용을 별도 폴더에도 복사해 둡니다.
3. git log -5 --oneline으로 최근 커밋과 현재 작업이 포함된 커밋 ID를 기록합니다. 본인이 만든 작업인지 메시지만 보지 말고 내용을 대조합니다.
4. 보존할 커밋에 머물러 있다면 다음 단계로 넘어갑니다. 이 시점에 단순히 main으로 이동하면 새 커밋에 붙어 있던 유일한 위치를 놓칠 수 있습니다.

브랜치 생성은 미커밋 파일의 자동 커밋이나 원격 백업이 아닙니다.

2. 현재 커밋에서 새 브랜치 만들기

1. git switch -c rescue-work를 실행합니다. 공식 문서의 -c는 새 브랜치를 만든 뒤 전환하는 옵션이며 시작점을 생략하면 현재 위치를 사용합니다.
2. git status로 현재 브랜치가 rescue-work인지 확인합니다. git log -5 --oneline으로 보존할 커밋이 그대로 보이는지도 확인합니다.
3. 미커밋 변경이 남아 있으면 필요한 파일만 검토하고 프로젝트의 커밋 절차를 따릅니다. 비밀키·개인정보·빌드 결과까지 무작정 추가하지 않습니다.
4. 작업이 안전하게 보존된 뒤 기존 개발 브랜치에 합칠지 별도 검토합니다. 병합이나 cherry-pick은 팀 정책과 충돌 가능성을 확인한 다음 진행합니다.

git switch -C는 기존 브랜치를 지정한 시작점으로 재설정할 수 있으므로 이 보존 안내에서는 사용하지 않습니다. 브랜치 생성 뒤 원격에 보내려면 별도 push가 필요하며, 로컬 브랜치만 만든 상태는 원격 백업과 다릅니다.

3. 이미 이동했다면 reflog로 찾기

1. git reflog를 실행합니다. HEAD reflog는 로컬 저장소에서 최근 위치 이동과 브랜치 전환 등을 기록합니다.
2. detached HEAD에서 만든 마지막 커밋의 ID를 찾습니다. 목록의 첫 줄이나 특정 HEAD@{번호}를 무조건 선택하지 말고 시각·메시지·전환 전후 기록을 대조합니다.
3. git show --stat 커밋ID로 변경 파일을 확인합니다. ‘커밋ID’는 그대로 입력하는 글자가 아니라 실제 찾은 해시로 바꿀 자리입니다.
4. 대상이 맞으면 git branch rescue-work 커밋ID로 해당 커밋에 이름을 붙입니다. 이것은 현재 작업 트리를 전환하지 않고 보존 지점을 만드는 방법입니다.
5. 미커밋 파일을 보관한 뒤 필요할 때 git switch rescue-work로 전환합니다. 거절 메시지가 나오면 강제 전환하지 말고 파일 변경을 먼저 점검합니다.

reflog는 해당 로컬 저장소의 기록이지 원격 서비스의 영구 복구 기능이 아닙니다. 정리·만료·객체 제거 상태에 따라 오래된 작업이 남아 있다는 보장은 없습니다.

주의사항과 해결되지 않을 때

• --discard-changes, -f는 변경을 버릴 수 있습니다. 빠른 해결을 위해 붙이지 않습니다.
• switch가 없으면 공식 checkout 문서의 git checkout -b 새브랜치를 대안으로 검토합니다.
• reflog에서 찾지 못했다면 같은 로컬 저장소인지, 다른 worktree나 다른 기기에서 작업했는지 확인합니다. 이미 제거된 객체의 복구는 보장할 수 없습니다.
• 기록 되돌리기는 Git revert와 reset 차이를, 원격 push가 거절되면 non-fast-forward 오류 점검 순서를 확인합니다. 별도 절차이므로 즉시 이어 실행하지 않습니다.

FAQ

Q1. detached HEAD는 오류인가요?

반드시 오류는 아닙니다. 특정 커밋을 확인하거나 실험할 때 쓰는 상태입니다. 계속 보관할 새 커밋이 생겼다면 브랜치 이름을 붙여 관리하는 편이 좋습니다.

Q2. 새 브랜치를 만들면 수정 파일도 자동 저장되나요?

아닙니다. 브랜치 생성과 파일 커밋·외부 백업은 별개입니다. git status로 미커밋 상태를 확인하고 필요한 파일을 검토하여 보관해야 합니다.

Q3. main으로 돌아간 뒤에도 항상 복구할 수 있나요?

보장할 수 없습니다. reflog와 객체가 남아 있으면 찾을 수 있지만 로컬 기록의 만료·정리 상태에 따라 달라집니다. 발견한 커밋에 먼저 이름을 붙이세요.

공식 출처

• Git: git-switch, -c와 강제 전환 옵션
• Git: git-checkout, DETACHED HEAD 설명
• Git: git-reflog, 로컬 기록과 만료 옵션