[Git & Github] 19. Reflog의 힘 - '사라진' 작업 복구하기

Important

• reflog 파일 탐색
• reflog 명령어
• 잃어버린 커밋 복구
• 리베이스 되돌리기

 

Nice To Have

• 시간 기반 reflog 수식자

 

reference log의 약어이다.

커밋을 잃어버리거나 rebase를 하지 말아야 할 때 rebase를 하는 등 문제를 되돌리고 싶을 때 사용한다.

깃을 실수 없이 올바르게 사용한다면 다룰일이 없는 명령어이기도 하다.

 

그리고 지역적이다. 내 컴퓨터의 참조목록에 대한 변경사항만을 저장하고 기록한다.

또한 로그가 영구적으로 남지 않고 기본 설정으로는 90일 정도 지나면 삭제된다.

 

 

git reflog

show, expire, delete, exists 총 4가지의 하위 명령어와 같이 사용하지만 show 말고는 별로 사용되지 않는다.

git reflog show <ref> : ref의 이력을 모두 확인한다.

 

HEAD~2와 HEAD@{2}는 다르다. HEAD~2는 커밋의 조부모로 거슬러 올라가는 것이고 HEAD@{2}는 HEAD의 2항목 이전의 움직임이다. 커밋이 아니라 단순히 switch일수도 있는 것이다.

 

 

$ git reflog main@{2}
$ git reflog show main@{2.days.ago}
$ git reflog show main@{one.week.ago}
$ git reflog show main@{yesterday}

 

reflog의 모든 항목에는 타임 스탬프가 존재하기 때문에 항목 지정 뿐만 아니라 날짜를 지정할 수도 있다.

 

 

사라진 커밋 복구

reset으로 커밋이 사라지더라도 로그에는 남아있게 된다.

 

로그의 참조값으로 다시 reset을 하면 사라졌던 커밋이 복구된다.

 

리베이스 취소

위와 같이 interactive rebase로 커밋을 정리했는데 실수였다는게 판단되면 reflog로 되돌리면 된다.

 

flowers@{2} 또는 해당 해시로 돌아가면 그대로 복구된다

 

복구 완료

reflog와 reset을 이용해서 삭제된 커밋이나 잘못된 리베이스를 되돌릴 수 있다.

 

명령어로 커밋들을 삭제한다고 해서 실제로 삭제되는것이 아니라 댕글링 커밋이 된다.

reflog는 모든 로그가 남기때문에 댕글링 커밋들을 되살릴 수 있는것이다.

 

앞서 언급했듯이 reflog는 지역적이고 영구적이지 않다는 것을 명심해야 한다.