Post

git reflog를 활용한 삭제된 브랜치 복구 방법

git reflog를 활용한 삭제된 브랜치 복구 방법

들어가며

Git을 사용하다 보면 얘기치 않은 상황과 마주할 때가 있습니다. 최근 저는 git stash로 작업을 임시 저장한 후 브랜치를 재정비하는 과정에서, 저장했던 작업 내용이 올바르게 적용되지 않는 문제를 겪었습니다. 이 글에서는 해당 문제의 원인을 분석하고, Git의 reflog 명령어를 사용해 삭제된 브랜치를 안전하게 복구했던 과정을 공유하고자 합니다.


문제 상황 분석

문제는 다음과 같은 순서로 작업을 진행했을 때 발생했습니다.

  1. feature/#114 브랜치에서 기능 개발 완료 후, git stash로 변경 사항을 임시 저장했습니다.
  2. 이후 feature/#114 브랜치를 로컬에서 삭제했습니다.
  3. 최신 버전인 origin/release/v0.0.3 브랜치에서 다시 feature/#114라는 이름으로 새로운 브랜치를 생성했습니다.
  4. 새로운 브랜치에서 git stash apply를 실행했으나, 변경 사항이 제대로 적용되지 않았습니다.

문제의 원인git stash가 브랜치 이름이 아닌, 특정 커밋을 기준으로 변경 사항을 저장하기 때문입니다. 제가 새로 생성한 feature/#114 브랜치는 이전 브랜치와 이름만 같을 뿐, 기반이 되는 커밋 히스토리가 전혀 다른 상태였습니다. 따라서 Git은 stash에 저장된 변경 사항을 새로운 커밋 히스토리에 올바르게 적용하지 못했던 것입니다.


해결 과정: git reflog의 활용

문제를 해결하기 위한 목표는 명확했습니다. ‘삭제하기 전의 feature/#114 브랜치의 상태로 돌아가는 것’이었습니다. 이를 위해 Git의 reflog 기능을 활용했습니다.

git reflogHEAD의 변경 이력을 모두 기록하는 명령어입니다. 이를 통해 로컬 저장소에서 수행했던 작업 내역을 확인하고, 필요한 시점으로 복원할 수 있습니다.

1단계: 현재 브랜치 이름 변경

우선, 작업하던 브랜치와의 충돌을 피하기 위해 현재 브랜치의 이름을 백업용으로 변경했습니다.

1
2
# 현재 feature/#114 브랜치를 백업용 이름으로 변경
$ git branch -m feature/#114 feature/#114-backup

2단계: reflog로 복구할 지점 확인

git reflog를 실행하여 HEAD의 변경 이력을 확인하고, 제가 복구하고자 하는 커밋의 해시(hash) 값을 찾았습니다.

1
2
3
4
5
6
7
$ git reflog

a1b2c3d HEAD@{0}: checkout: moving from feature/#114 to feature/#114-backup
...
e4f5g6h HEAD@{5}: checkout: moving from feature/#114 to feature/#114 # 복구 목표 지점
c7d8e9f HEAD@{6}: commit: (Initial commit)
...

3단계: 브랜치 복구

복구할 지점의 커밋 해시를 확인한 뒤, checkout 명령어를 사용해 해당 지점을 기준으로 새로운 브랜치를 생성하며 복구를 완료했습니다.

1
2
# reflog에서 찾은 커밋 해시를 기준으로 브랜치를 다시 생성
$ git checkout -b feature/#114 e4f5g6h

이 과정을 통해 삭제했던 브랜치와 작업 내용을 모두 성공적으로 복원할 수 있었습니다.

결론 및 회고

이번 경험을 통해 Git의 내부 동작 원리를 이해하는 것이 얼마나 중요한지 다시 한번 깨닫게 되었습니다. 이번 문제 해결 과정에서 얻은 주요 사항은 다음과 같습니다.

git stash의 동작 원리 이해: stash는 브랜치가 아닌 커밋 히스토리를 기반으로 동작하므로, 다른 히스토리를 가진 브랜치에 적용 시 주의가 필요합니다.

git reflog의 중요성: reflog는 로컬 저장소의 모든 변경 이력을 추적하므로, 실수로 인한 데이터 유실을 방지하는 강력한 도구입니다.

체계적인 문제 해결: 문제가 발생했을 때, 현재 상태를 안전하게 백업하고 원인을 분석한 후 해결을 시도하는 것이 중요합니다.

Git은 강력한 도구인 만큼, 그 동작 방식을 깊이 이해하고 사용할 때 더욱 안정적으로 버전 관리를 할 수 있습니다. 이 글이 비슷한 문제를 겪는 개발자분들께 도움이 되기를 바랍니다.

This post is licensed under CC BY 4.0 by the author.