Git 커밋을 잃어버렸을 때: reflog 확인 후 복구 브랜치부터 만드는 순서

직접 생성한 개념 이미지입니다. 실제 서비스 화면이나 구축·성능 시험 결과가 아닙니다.

reset이나 rebase 뒤 커밋이 보이지 않으면 먼저 로컬 reflog에서 후보를 찾고 내용을 확인하세요. 바로 reset --hard를 실행하기보다 새 복구 브랜치를 만들어 후보 커밋을 보존하는 편이 현재 작업을 보호하기 쉽습니다.

적용 환경: reflog와 해당 커밋 객체가 남아 있는 로컬 Git 저장소. 자료 확인일: 2026-10-25. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.

1. 원인: 현재 브랜치에서 안 보이는 것과 삭제는 다릅니다

reflog는 로컬 참조가 이동한 기록입니다. HEAD 기록에는 브랜치 전환도 포함됩니다. 일반 커밋 이력과 다르며 원격 저장소와 같은 기록을 공유한다고 가정하면 안 됩니다.

이 방법은 커밋 객체와 필요한 기록이 남아 있을 때의 경로입니다. 커밋하지 않은 파일, 이미 정리된 객체, 다른 사람 PC의 기록까지 모두 복구하는 기능은 아닙니다.

2. 해결: 읽기 확인 뒤 새 이름으로 보존

먼저 대상 저장소의 작업 폴더인지 확인합니다. 아래 첫 묶음은 현재 상태와 기록 조회 예시입니다. 출력 결과는 이 글에 만들어 넣지 않았습니다.

git status --short
git reflog show HEAD --date=iso

기록에서 후보 커밋 ID를 직접 확인한 뒤, 아래 COMMIT_ID를 그 값으로 바꾸세요. 브랜치 이름도 기존 이름과 겹치지 않는 것으로 정합니다.

git show --stat COMMIT_ID
git show COMMIT_ID
git branch rescue/recovered-work COMMIT_ID

마지막 명령은 새 브랜치를 만들며 현재 작업 폴더로 전환하지 않습니다. 먼저 내용을 살펴보려는 목적에 맞는지 확인하세요. 기존 브랜치를 강제로 이동하는 -f 옵션은 사용하지 않습니다.

3. 확인: 필요한 변경이 실제 포함됐는지 비교

확인	의미
커밋 메시지·시각	후보를 좁히는 단서
변경 파일·diff	찾던 수정이 있는지 판단
새 브랜치 참조	커밋을 가리키는 보존점
작업 폴더 상태	현재 미커밋 변경 보존 여부

새 브랜치의 변경을 읽은 뒤 필요한 병합이나 cherry-pick은 별도 작업으로 판단하세요. 복구 브랜치 생성만으로 현재 브랜치의 내용이나 원격 서버가 바뀐 것은 아닙니다.

4. 주의와 FAQ

HEAD@{1}을 그대로 써도 되나요? 참조는 이후 작업으로 달라질 수 있습니다. 지금 관찰한 커밋 ID와 실제 내용을 확인해 사용하세요.

reflog가 비어 있으면요? 다른 저장소인지, 기록이 보존됐는지부터 확인합니다. gc나 prune을 복구의 첫 단계로 실행하지 마세요.

미커밋 파일은 별도로 보존하고, reset --hard·강제 push·브랜치 삭제는 이 절차에 포함하지 않습니다. 이 글은 공식 문서 확인에 기반하며 실제 사용자 저장소에서 복구를 시험한 결과가 아닙니다.

공식 출처와 관련 글

git-reflog

git-branch

git-show

작업 트리·인덱스·HEAD 비교