Git reflog로 삭제한 브랜치와 reset 전 커밋 복구하기
브랜치 삭제나 hard reset 뒤 필요한 커밋이 log에서 보이지 않는다는 상황에서 원인을 구분하고 안전하게 수정·검증하는 순서를 정리합니다.
짧은 요약
브랜치 삭제나 hard reset 뒤 필요한 커밋이 log에서 보이지 않는다면 설정을 전부 초기화하기보다 관찰 가능한 증거로 원인 경계를 먼저 좁히는 편이 안전합니다. 핵심은 reflog에서 정확한 커밋을 검토하고 새 브랜치로 참조를 복원한다.
증상과 환경
- 분류: Git
- 관련 도구: Git
- 운영체제: Cross-platform
브랜치 삭제나 hard reset 뒤 필요한 커밋이 log에서 보이지 않는다. 오류 직전 변경, 전체 메시지, 실행 위치와 버전을 함께 남겨야 비슷해 보이는 다른 문제와 구분할 수 있습니다.
원인
브랜치 참조는 사라졌지만 로컬 reflog에 HEAD 이동 기록과 객체가 남아 있을 수 있다. 표면적인 오류 문구만 보고 권한 확대나 전체 캐시 삭제부터 하면 원인을 숨기거나 복구 범위를 넓힐 수 있습니다.
재현 예시
새 임시 작업 공간이나 영향이 제한된 테스트 환경에서 같은 명령과 입력을 사용합니다. 정상 기준과 실패 기준을 하나씩 준비하고, 차이가 생기는 첫 단계의 출력만 비교합니다. 운영 환경의 비밀값과 개인정보는 로그에 남기지 않습니다.
단계별 해결법
1. 오류가 난 시각, 실행 계정, 버전과 원문 로그를 보존하고 브랜치 삭제나 hard reset 뒤 필요한 커밋이 log에서 보이지 않는다 상태를 최소 입력으로 다시 확인합니다.
2. 아래 진단 명령을 읽기 전용 단계부터 실행해 “브랜치 참조는 사라졌지만 로컬 reflog에 HEAD 이동 기록과 객체가 남아 있을 수 있다” 가설이 실제 환경과 맞는지 확인합니다.
3. reflog에서 정확한 커밋을 검토하고 새 브랜치로 참조를 복원한다. 한 번에 여러 설정을 바꾸지 말고 변경 하나마다 결과를 기록합니다.
4. 같은 입력으로 수정 전후를 비교하고, 새 세션이나 깨끗한 작업 환경에서도 결과가 재현되는지 확인합니다.
코드·명령 예문
git reflog --date=iso
git show <commit>
git branch rescue/recovered <commit><host>, <path>, <package>, <container> 같은 자리는 실제 값으로 바꿉니다. 삭제·강제 갱신 명령은 백업과 대상 확인 뒤에만 사용합니다.
확인법
오류를 만들었던 동일한 입력을 다시 실행해 성공 여부와 종료 코드를 확인합니다. 이어서 관련 테스트를 두 번 실행하고, 로그에 새로운 경고가 없는지 봅니다. 네트워크나 분산 환경 문제는 한 클라이언트 결과만으로 결론 내리지 말고 다른 경로에서도 확인합니다.
주의사항
검증을 끄거나 관리자 권한으로 상시 실행하는 우회는 적용하지 않습니다. 원격 저장소, 이미지, 잠금 파일처럼 팀이 공유하는 상태를 바꿀 때는 diff와 롤백 지점을 먼저 확보하세요. 예문은 진단 순서를 보여 주므로 사용 중인 버전의 공식 문서에서 지원 옵션을 다시 확인해야 합니다.
관련 이슈
- reflog-recovery
- 실행 환경과 구성 파일의 불일치
- 캐시·자격 증명·중간 계층이 남긴 이전 상태
- 자동화 환경과 로컬 환경의 차이