문제 상황

Pull Request에는 분명히 5일전(25일) 2개, 4일 전(26일) 3개, 오늘(30일) 1개의 PR이 머지 되었다.

그런데 develop브랜치의 커밋에는 오늘(30일) 1개, 4일 전(26일) 3개, 그리고 나머지는 1주일 이전이다.

보니까, master브랜치가 당겨져온 듯하다. master의 커밋이 develop으로 옮겨져온 것이다.

원인 분석

이러한 일을 해결하는 데에는 다양한 방법이 있겠지만, 나중에 같은 일이 있지 않기 위해서 원인을 파악하는 것이 가장 먼저라고 생각했다. 다양한 원인을 생각해보았다.

1. reset을 잘못 입력했다.

   

   git reflog로 확인한 git 내역이다. 가장 상단에 reset 2개는 내가 테스트용으로 한 번 해본 것이다. 들여다본 결과, 의심이 되는 reset은 없다.

   Head@{42}의 reset:moving to HEAD는 599브랜치에서 있었던 일이고, HEAD@{53}의 reset: moving to 5b~는 이전에 테스트용으로 개발서버에 배포했던 사항을 되돌린 커맨드이다.

2. rebase를 잘못했다.

   

   의심이 되는 커밋이다. master에서 develop를 rebase할 일이 있을까? master변경 사항을 develop에 반영하기 위해서는 develop에서 master를 rebase하여 pull해야한다. develop변경 사항을 master에 반영하기 위해서는 cherry pick해야한다.

   6856~이 커밋이 바로, 현재 오늘 커밋 제외하고 반영된 가장 최신 커밋이다.

   

   이 rebase가 연관이 되어있는 듯하다. 하지만 해당 커밋은 master에서 develop을 rebase한 것으로, develop브랜치에 영향을 줄 수 없다.

   develop에서 git pull origin master —rebase를 수행할 경우, master브랜치의 변경 사항을 develop브랜치 위에 배치한다. rebase를 하면 커밋 해시값이 변경되며 커밋이 한 번 더 생성되면 생성이 되었지, 제거되지는 않는다.

3. 팀원이 reset을 잘못했다.

   팀원이 어제 master브랜치에서 .yarn을 제거를 하여 commit을 올리고, 이 커밋을 다시 되돌리기 위해 개인 저장소에서 git reset을 실행했다. 이 과정에서 무언가 오류가 있었던 것 같다.

   reset을 평소에도 조심히 사용해야하고, 함께 작업할 때는 특히 유의를 해야한다. 그럼에도 commit이력을 깨끗이 사용하기 위해서 가끔씩 사용했는데, 이런 문제를 일으킬 줄 몰랐던 것이다.

   <aside> ❓ revert? reset?

   1. reset : 커밋을 삭제한다.
      • git reset —-option (돌아갈 커밋)
      • git reset HEAD~2 / git reset HEAD^
      • git reset —hard (돌아갈 커밋) : 커밋 이후의 변경 이력 모두 삭제
      • origin에 올린 상태에서 reset하고 push하려면 —force옵션을 주어 기존 커밋을 덮어쓸 수 있다. 하지만, 다른 사람과 해당 레포를 공유하고 있다면 하면 안된다.
   2. revert : 커밋을 삭제하는 것이 아니라, 커밋을 추가한다.
      • reset과 명령어와 결과는 동일하지만, 이력에 Revert “..”메시지가 추가된다. </aside>

해결 과정

가장 마지막으로 반영이 되지 않은 커밋의 해쉬번호를 가져왔다.

git reset --hard 5b878c8 명령어로 이 때의 커밋 상태로 되돌렸다.

그리고, push를 하니 이전 커밋이 모두 돌아왔다.