실수로 삭제한 Git 브랜치와 커밋, Reflog로 1분 만에 되살리는 방법

Posted on by steve

 

실수로 삭제한 깃 브랜치나 사라진 커밋 때문에 눈앞이 캄캄해지셨나요? 깃(Git)의 최강 타임머신인 reflog를 활용하면 영구 삭제된 것처럼 보이는 코드도 1분 만에 거짓말처럼 되살릴 수 있습니다. 명령어 한 줄로 멘붕에서 탈출하는 실전 복구 노하우를 지금 바로 확인해보세요!

 

개발자라면 누구나 한 번쯤 등골이 오싹해지는 순간을 마주하곤 해요. 밤샘 코딩 후 피곤한 눈을 비비며 브랜치를 정리하다가 git branch -D feature/login 명령어를 입력하고 엔터를 친 순간, 혹은 잘못된 하드 리셋(reset –hard)으로 지난 며칠간의 소중한 커밋들이 터미널에서 증발해버렸을 때죠. 저도 예전에 금요일 퇴근 10분 전에 딱 이 실수를 저지르고 식은땀을 한 바가지 흘렸던 기억이 생생하답니다. 😭

하지만 너무 절망하지 마세요! 깃(Git)은 생각보다 훨씬 더 다정하고 치밀한 버전 관리 시스템이거든요. 여러분이 명시적으로 저장소를 통째로 날려버리지 않는 한, 로컬에서 생성된 커밋과 브랜치 포인터는 내부 데이터베이스 어딘가에 온전히 숨어있습니다. 오늘 소개해 드릴 Git Reflog(Reference Logs)만 제대로 다룰 줄 안다면, 방금 날려먹은 작업물도 99% 완벽하게 원상 복구할 수 있어요. 차근차근 따라와 보세요! 😊

 

1. Git Reflog란? 깃의 숨겨진 블랙박스 파헤치기 🤔

보통 커밋 기록을 확인할 때 가장 먼저 떠올리는 명령어는 git log일 거예요. 하지만 브랜치를 강제 삭제하거나 리셋을 해버리면 일반적인 로그 창에는 해당 커밋들이 더 이상 보이지 않게 됩니다. 연결된 가지(참조 링크)가 끊어졌기 때문이죠. 이때 구원투수로 등장하는 도구가 바로 Reflog(참조 기록)입니다.

Reflog는 프로젝트의 커밋 족보를 보여주는 것이 아니라, 내 로컬 컴퓨터에서 HEAD 포인터가 이동한 모든 발자국을 초 단위로 기록하는 일종의 ‘블랙박스 비행 기록 장치’예요. 커밋 생성, 브랜치 전환(checkout/switch), 리셋(reset), 머지(merge), 리베이스(rebase) 등 사용자가 취한 모든 액션이 고스란히 남아있답니다.

💡 알아두세요!
Reflog 기록은 기본적으로 로컬 환경에만 보존되며 원격 저장소(GitHub, GitLab 등)로 푸시되지 않아요. 또한 깃의 가비지 컬렉터(GC)가 주기적으로 청소하기 전까지(참조되지 않은 커밋은 기본 30일, 일반 기록은 90일 동안) 로컬 디스크에 안전하게 유지되므로 당황하지 말고 즉시 복구를 시도하면 충분히 살려낼 수 있습니다!

비교 분석: git log vs git reflog

비교 항목 git log git reflog
기록 대상 현재 브랜치에 연결된 유효 커밋 히스토리 로컬 HEAD 참조 포인터의 모든 이동 내역
삭제된 커밋 조회 불가능 (브랜치 끊기면 표시 안 됨) 가능 (HEAD가 머물렀던 과거 지점 모두 표시)
보존 기간 저장소 히스토리에 영구 보존 로컬 기준 약 30~90일 후 가비지 컬렉션
주요 용도 프로젝트 변경 이력 파악 및 릴리즈 추적 실수 복구, 사라진 브랜치 및 커밋 되살리기

 

2. 삭제된 브랜치와 커밋 완벽 복구 3단계 프로세스 📊

복구 작업의 원리는 매우 단순해요. “1) reflog에서 과거의 커밋 해시(위치)를 찾고, 2) 그 자리에 깃발(새 브랜치)을 다시 꽂는다” 이것만 기억하시면 끝납니다. 구체적인 3단계 순서를 살펴볼게요.

📋 단계별 실전 가이드라인

1단계: 터미널에 reflog 호출하기
터미널을 열고 git reflog 명령어를 입력합니다. 화면에 HEAD@{0}, HEAD@{1} 같은 인덱스와 함께 작업 설명(commit, checkout, reset 등)이 역순으로 나열됩니다.

2단계: 사라지기 직전의 커밋 식별하기
목록을 천천히 위에서부터 훑어보며 내가 마지막으로 작업했던 커밋 메시지나 브랜치를 삭제하기 직전의 시점을 찾습니다. 해당 행 맨 앞에 적힌 7자리 커밋 해시(예: 4a2b1c9) 또는 HEAD@{2} 포인터를 메모해 둡니다.

3단계: 새 브랜치를 생성하여 복구 완료
찾아낸 커밋 지점을 가리키는 새로운 브랜치를 생성합니다.
👉 git checkout -b 복구할브랜치명 커밋해시 (또는 git branch 브랜치명 HEAD@{숫자})

⚠️ 주의하세요!
Reflog로 복구할 수 있는 것은 오직 최소 한 번 이상 커밋(commit)된 코드뿐입니다. 커밋이나 Stash(임시 저장)를 하지 않고 작성 중이던 작업 트리의 변경 사항을 git restore . 나 git checkout -- . 으로 날려버렸다면 깃 내부에는 기록이 전혀 남지 않아 reflog로도 복구할 수 없어요! 이런 경우엔 사용 중인 에디터(VS Code, IntelliJ 등)의 ‘Local History(로컬 작업 내역)’ 기능을 확인하셔야 합니다.

 

3. 상황별 복구 공식 & 복구 명령어 즉시 생성기 🧮

상황에 따라 복구하는 공식이 살짝 다릅니다. 가장 자주 일어나는 대표적인 3가지 상황별 공식을 먼저 정리해 드릴게요.

📝 유형별 깃 복구 공식 모음

• 브랜치 삭제 복구 공식: git checkout -b [삭제된브랜치명] [삭제직전_커밋해시]

• Reset –hard 취소 공식: git reset --hard HEAD@{리셋_이전_인덱스}

• 잘못된 Rebase/Merge 탈출: git reset --hard ORIG_HEAD (또는 reflog 시점으로 리셋)

복잡한 터미널 문법이 헷갈리실까 봐 바로 복사해서 쓸 수 있는 간편 생성기를 준비했어요. 본인의 상황과 해시를 입력하고 버튼을 눌러보세요!

🔢 Git 복구 명령어 자동 생성 도구

실수 유형 선택:

커밋 해시 / HEAD@{n}:

복구 브랜치 이름:


 

4. 실전 예시: 김 개발자의 아찔한 브랜치 복구 스토리 📚

실제 업무 현장에서 일어날 법한 시나리오를 통해 전체 복구 흐름을 생생하게 따라가 볼게요. 마감 30분 전 실수로 머지되지 않은 결제 기능 브랜치를 날려버린 김 개발자의 실전 구출 사례입니다.

사례 주인공의 위기 상황

  • 상황: git branch -D feature/payment를 잘못 실행하여 이틀 동안 작성한 카카오페이 결제 연동 커밋 4개가 모두 사라짐
  • 상태: 원격(GitHub)에 아직 푸시하지 않은 로컬 단독 커밋 상태라 팀원 저장소에도 백업이 없음

터미널 해결 및 복구 과정

1) Reflog 호출: 터미널에 git reflog를 실행하여 최근 기록을 출력

9a3f21b HEAD@{0}: checkout: moving from feature/payment to main
e7c41a2 HEAD@{1}: commit: PG 결제 승인 API 모듈 구현 완료 (← 발견!)
4b11f90 HEAD@{2}: commit: 결제창 팝업 UI 레이아웃 작업

2) 커밋 해시 확인: 삭제된 브랜치의 마지막 커밋이 e7c41a2임을 확인

3) 브랜치 재생성 명령 실행:

git checkout -b feature/payment e7c41a2

최종 복구 결과

– 결과 1: 삭제되었던 feature/payment 브랜치가 마지막 커밋 시점으로 100% 온전하게 재탄생

– 결과 2: 소요 시간 단 15초 만에 밤샘 코딩 분량의 소스코드를 무사히 구조 성공

어때요? 생각보다 훨씬 간단하죠? 깃은 개발자가 명시적으로 날린 줄 알았던 파일도 내부 객체 트리(Blob/Tree/Commit)에 그대로 간직하고 있기 때문에 해시 주소만 찾아주면 언제든 즉시 부활시킬 수 있답니다. 👍

📌 알아두세요!
만약 커밋 해시가 reflog에서도 너무 뒤로 밀려 찾기 어렵다면, git fsck --lost-found 명령어를 사용해보세요. 어디에도 연결되지 않은 고아(dangling) 커밋 객체들을 전부 검색해서 보여주므로 최후의 수단으로 아주 유용합니다.

 

마무리: 핵심 내용 요약 📝

오늘 배운 Git Reflog 복구의 핵심 내용을 네 줄로 간결하게 요약해 드릴게요. 이것만 머릿속에 기억해 두셔도 앞으로 깃 때문에 가슴 철렁할 일은 없을 거예요!

  1. Reflog는 로컬 블랙박스: HEAD가 움직인 모든 궤적을 기록하므로 일반 로그에서 지워진 커밋도 다 찾아낼 수 있습니다.
  2. 복구의 본질은 포인터 재연결: 잃어버린 시점의 커밋 해시를 찾아 git checkout -b [브랜치명] [해시]를 실행하면 즉시 복원됩니다.
  3. 골든타임 존재: 로컬 가비지 컬렉터가 작동하기 전(통상 30일 이내)에 복구 작업을 진행해야 안전합니다.
  4. 최선의 방어는 잦은 커밋: 커밋되지 않은 인덱스 상태의 파일은 reflog로도 복구가 어려우니 작업 중간중간 WIP 커밋이나 Stash를 애용하세요.

💡

Git Reflog 복구 치트시트

✨ 첫 번째 핵심: 모든 액션의 추적자 – 커밋, 머지, 리셋 등 로컬 HEAD의 전 과정을 기록합니다.
📊 두 번째 핵심: 초간단 2단계 복구 – reflog에서 해시 확인 후 새 브랜치로 분기 연결!
🧮 세 번째 핵심 (만능 공식):

git checkout -b [복구할브랜치명] [과거_커밋해시]

⏱️ 네 번째 핵심: 골든타임 30일 – 가비지 컬렉션(GC) 실행 전에 즉시 조치하세요.

커밋되지 않은 스테이징 이전 변경점은 복구되지 않으므로 수시 커밋 습관을 권장합니다.

 

자주 묻는 질문 ❓

Q: reflog 기록은 원격 저장소(GitHub)에도 공유되나요?
A: 아닙니다! reflog는 오직 사용자의 로컬 PC(로컬 깃 저장소)에만 저장되는 개인 참조 기록이에요. 다른 팀원의 컴퓨터나 깃허브 원격 저장소에는 공유되지 않습니다.

Q: 커밋을 전혀 하지 않고 작업 중이던 코드를 날렸는데 reflog로 살릴 수 있나요?
A: 안타깝게도 커밋이나 Stash 기록이 단 한 번도 없었던 파일은 깃 객체로 등록되지 않아 reflog로 복구할 수 없습니다. 이 경우 VS Code의 ‘타임라인(Timeline)’이나 IntelliJ의 ‘Local History’ 기능 확인을 추천합니다.

Q: 실수로 삭제한 커밋은 언제 완전히 사라지나요?
A: 깃은 연결이 끊긴 고아(unreachable) 커밋 객체를 기본 30일 동안 보존합니다. 이후 git gc(가비지 컬렉션)가 실행될 때 영구 삭제되므로, 한 달 이내라면 언제든 복구할 수 있습니다.

Q: git reset –hard 명령어로 날린 커밋도 정말 100% 돌아오나요?
A: 네, 이미 커밋된 내용이라면 100% 완벽 복구됩니다! reflog에서 reset 직전의 커밋 인덱스(예: HEAD@{1})를 찾아 git reset --hard HEAD@{1}을 실행하면 원상 복구됩니다.

Q: VS Code나 GitKraken 같은 GUI 툴에서도 reflog 복구가 가능한가요?
A: 가능합니다. GitKraken이나 SourceTree 등의 GUI 도구에는 ‘Show Reflog’ 메뉴가 지원되며, VS Code에서는 내장 터미널을 열어 명령어를 입력하거나 GitLens 확장 프로그램의 ‘Search & Compare’ 기능을 통해 손쉽게 복구할 수 있습니다.


지금까지 깃(Git)의 숨겨진 타임머신인 reflog를 이용해 삭제된 브랜치와 커밋을 되살리는 방법을 꼼꼼히 알아보았어요. 실수는 누구나 할 수 있지만, 복구할 줄 아는 기술이 있다면 더 이상 브랜치 삭제 앞에서도 두렵지 않겠죠? 작업 중 복구가 잘 안 되거나 막히는 명령어가 있다면 언제든 편하게 댓글로 물어봐주세요~ 함께 해결해 봐요! 😊