Critical
Important
Exploring Reflog Files
reflog는 reference log의 줄임말로 깃이 우리들을 위해 보관하는 레퍼런스 기록이다. 깃은 레퍼런스에 변경 사항이 있을 때마다 깃이 기록을 남기고 이것들을 파일에다가 저장해둔다.
.git 안에 logs 폴더로 들어가 HEAD 파일을 보면 헤드 참조의 이동을 볼 수 있다. 만약에 브랜치를 마스터에서 turtle로 바꾼다면, 아래와 같은 그림이 나온다.
Limitations
reflog 은 지역적(local) 이라는 것을 알고 있어야한다. 다른 사람들의 reflog를 알 수는 없다. 즉 내 컴퓨터의 상황만 알 수 있고 그리고 만료가 된다는 사실을 알고 있어야한다. 90일쯤 되면 만료가 된다.
The Git Reflog Command
이 명령은 네개의 하위 명령과 함께 쓸 수 있지만 하나만 주의해서 알고 있으면 된다.git reflog show HEAD 이다. 나머지 expire, delete ,exists는 잘 사용하지 않는다. 커밋을 삭제하고 커밋을 한 것도 확인 가능하다. 가장 아래있는 것이 오래된 것이고 가장 위에 있는 것이 가장 최근 것이다. HEAD@{0} 은 가장 최근이고 숫자가 커질 수록 옛날 것이다. 이 문법은 나중에 사용할 일이 있다.
name@{qualifier} 이것은 참조를 위해 reflog에서 항목을 얘기하는 방법이다. 이것은 다른 명령어에서 사용 가능하다. 예를 들어 git reflog show HEAD@{10}을 하면 처음부터 HEAD@{10} 까지를 보여준다. 또한 git checkout HEAD@{2} 라고 하면 HEAD가 두번 행동 전에 커밋이 있는 곳으로 간다. 또한 git diff HEAD@{0} HEAD@{5}을 할 수도 있다.
Rescuing Lost Commits With Relog
커밋을 잃어버린 뒤 reflog 를 통해 데이터를 복구하는 방법을 알아보겠다. 간단한 상황 하나를 가정해보자. 만약에 git reset --hard <commit hash>를 하면 커밋 해쉬로 돌아가서 그보다 더 늦게 만들어진 커밋을 전부 없애버린다. 또한 작업 중이던 워킹 디렉토리도 없어지게 된다. 이 상황에서 다시 변경 사항을 복구시키고 싶다면 어떻게 해야할까? 정보가 아직 reflog에 존재한다.
위의 사진을 보면 47aa48e가 우리가 방금 없앤 커밋 해시이다. 이 상황에서 git checkout 47aa48e를 하게 되면 아래의 상황이 된다.
이 상황에서 47aa48e 커밋은 부모와 자식이 없는 상태로 존재하게 된다. 그러나 우리는 다시 복원할 수 있다. 이 상황에서 git reset --hard master@{1} 을 하게 되면 master@{1} 으로 돌아가서 그 이후 상황은 없애버린다 .
Undoing Rebases With Reflog
이번에는 rebase를 수행하는데 이는 새로운 커밋을 생성하는 것이다. 만약에 커밋을 flowers 브랜치에서 커밋을 여러개 했는데, 그 후에 커밋을 통합했는데 다시 과거의 것 즉 나눠진 것을 원한다면 어떻게 해야할까? 그러면 git reflog flowers 를 한 뒤에 git reset --hard flowers@{2}를 하면 된다.
Nice To Have
Time-Based Reflog Qualifilers
reflog 의 모든 항목 하나하나에는 시간이 기록되어있다. 이때 사용하는 항목은 master@{one.week.ago} 와 같다. 또한 main@{yesterday} 처럼 사용가능하다. git deiff master master@{yesterday} 를 하면 어제와 오늘의 마스터브랜치 차이를 알 수 있다.
