git reset --hard 경험 기록

팀원의 머지 실수로 과거의 기록들이 현재의 작업들을 덮어서 일주일치 기록이 덮여버렸습니다. 단순히 파일 수정으로 기록을 덮는 방법은 할 수 없어서 문제가 있는 머지 기록 이전으로 돌아가자는 판단을 했습니다. 그래서 git reset --hard를 해본 경험과 github desktop의 Update from <default branch> 버튼의 올바른 사용방법에 대해서 정리를 합니다.

---

[ 문제가 일어난 커밋 ]

---

[ 문제가 일어난 원인 ]

팀원은 github desktop을 사용하고, forked repository를 clone 하여 로컬에서 사용 중이었습니다. 팀원은 feature 브랜치에서 작업 중에 커밋기록이 있는 상태에서 Update from develop을 진행한 후 PR과 Merge를 진행했습니다. 

 

여기서 문제점은 Update from develop을 했을 때 sync fork를 진행하지 먼저 하지 않아서 일주일 전의 develop 브랜치의 기록을 당겨왔으며, 현재 commit 기록도 브랜치가 가지고 있었기 때문에, rebase가 아닌 merge가 된 부분이 화근입니다.

 

[ 해당 문제를 방지하는 방법 ]

문제가 일어나지 않도록 되도록 팀원이 머지를 했을 때는 sync fork를 해주고, Update from develop은 해당 브랜치의 commit 키록이 없을 때나, PR 과 Merge를 통해 conflict가 없거나 해결된 후에 해주는 것이 좋다고 판단을 했습니다. 그래야만 merge가 일어나지 않고 rebase가 일어나기 때문에 commit 기록들도 깔끔해지고, conflict나 과거의 기록이 덮이는 문제가 없습니다.

---

[ 과거 버전으로 돌아가기 및 기록 삭제 방법 ]

저의 마지막 머지 기록입니다. 저도 불과 몇달 전만 해도 github desktop의 Update from 버튼의 무서움을 몰랐습니다. 터미널에 git reset --hard <이동할 커밋 주소>를 입력했습니다.

---

위의 이미지처럼 develop 브랜치가 제가 머지를 했었던 버전으로 돌아왔습니다. 

---

그 다음 git push -f origin <브랜치명> 을 통해서 origin의 기록도 일치 시켜줍니다. 제 계정이 upstream repository로 사용되고 있기 때문에 upstream이 아닌 origin입니다!

---

문제가 되었던 merge 기록이 사라졌습니다. 사실 기록은 남아있기 때문에 복구를 하려면 방법이 있습니다. 검색을 해봤던 경험으로는 30일 정도 기록이 남아있다고 들었습니다!

 

[ 문제된 머지 커밋 후처리 과정 ]

팀원의 경우엔 forked repository 였기에 문제가 없었던 팀원의 머지기록을 기준으로 변경된 파일들을 따로 빼두고, forked repository를 지우고, 다시 저의 repository를 fork 해서 로컬로 clone을 했습니다.

 

그 후에 빼뒀던 파일들을 다시 넣어서 커밋한 후에 다시 PR을 진행했습니다.

---

[ Branch protection rule 추가 ]

---

머지의 위험성을 이번 경험을 통해 알게 되고, 비대면으로 팀원가 협업하다보니, 팀원의 코딩 진행상황을 파악하지 않게 되거나, 소통을 안하는 문제가 있었습니다. 그래서 강제로 approvals를 추가하여 서로의 코드를 PR 할 때마다 검수해주는 것으로 팀원간의 협업에 문제가 없도록 했습니다. 그리고 제가 프론트엔드 팀원의 멘토로서 페어 프로그래밍을 진행하기 때문에, 저의 개발 속도가 빨라서, 강제로 머지를 할 수 있는 설정도 추가했습니다. 후에 github으로 협업하는 과정을 글로 추가했습니다!

 

 

풀리퀘스트 리뷰하는 방법 정리