GitHub Desktop 복구 과정에 대해...🥲

💭깃(Git) 사용 중에 발생한 문제를 어떻게 해결했는지에 대한 그 과정을 정리해보고자 한다. 이번 글에서는 문제 발생부터 복구, 그리고 나중에 동일한 문제가 생겼을 때 대비할 수 있는 방법까지 초보자도 따라할 수 있도록(내가 초보자니까...) 사고의 흐름에 따라 작성했다. 이 방법이 알맞는 방법인지는 잘 모르겠지만... 어찌 해결은 하였다.

---

1. 문제 상황과 처음 접근

팀 작업 중에 커밋을 하고 머지를 하는 과정 중에 뭔가 꼬였다... 업데이트한 UI가 반영이 안되고 이전에 만들어둔 UI 위젯 블루프린트가 적용돼서 나타난다...(태초마을😂)

 

문제가 생긴 시점을 파악하기 위해 깃허브 데스크탑의 History 탭을 열어 최근 커밋들을 살펴보았고

오른쪽 클릭으로 메뉴를 열어 백업 기능이 있는지 둘러보았다.

여기서 두 가지 기능이 눈에 띄었다.

Reset 활성화 되지 않았네?.

• Revert : 특정 커밋만 선택하여 그 변경 사항만 취소한다.
  • 장점: 이후의 다른 작업 내역은 그대로 유지.
  • 단점: 여러 커밋에 걸친 문제가 발생했다면, 하나하나 취소해야 하는 번거로움이 있을 수 있다.
• Reset : 선택한 커밋으로 브랜치 포인터를 되돌려, 해당 커밋 이후의 변경사항을 되돌린다
  • 장점: 문제 발생 이전 상태로 깔끔하게 돌아갈 수 있습니다.
  • 단점: 이미 원격 저장소에 반영된 작업 내역이 있다면 강제 푸시(force push)가 필요할 수 있어, 협업 환경에서는 주의!

이 두 가지 옵션 중 Revert만 쓸 수 있었기 이걸 먼저 써보기로 했다.

(지금 복기해보자면 첨부터 백업 브랜치를 생성하는 게 나았을텐데...)

“문제가 발생하기 전 마지막 정상 상태”의 커밋을 찾았다.

---

2. 복구 진행 과정과 예상치 못한 문제들

처음에는 깃허브 데스크탑에서 Revert 기능을 사용해 문제 이전 상태로 돌아가기를 바랬다. 그런데 단순히 되돌리는 것만으로는 해결되지 않는 부분들이 있었다. “Changes” 탭에 여전히 남아있는 변경 사항이나 머지(Merge) 충돌이 발생하고 있어서 그런지 복구가 되지 않았다.

그래서 아래와 같은 절차를 추가로 진행했다.

1. 커밋 및 푸시 작업: 일단 현재 상태를 임시로 커밋하고 푸시했다.
2. 백업 브랜치 생성: 원래 작업하던 브랜치가 계속 문제가 생기자, 정상인 커밋 포인트 찾아서 백업 브랜치를 만들었다📍
3. 머지 테스트: 백업 브랜치에서 기존 작업 브랜치로 머지하는 과정을 거치며, 충돌이나 깨진 부분이 없는지 확인했다.

➡️ 백업 브랜치에서는 프로젝트 정상확인! 그러나 백업에서 기존 브랜치로 머지했더니 같은 증상이 발생... 기존 작업 브랜치는 버려야 될 거 같다. 아무튼 백업 브랜치에서 테스트메인 브랜치로 머지하니 정상을 확인할 수 있었다!

Create branch from commit

---

3. 추가 팁

• 무조건 커밋: 커밋하는 습관은 정말 중요하다... 정상 동작하는 커밋 지점이 없었으면 처음부터 했어야 했다...
• 메인의 백업 브랜치(테스트 메인)를 만들어 두어서 메인 브랜치가 꼬이는 사태를 방지하였다.
• 충돌 시 해결 방법 기록하고 공유: 복구 과정 중 발생한 충돌이나 오류 메시지를 기록해두고, 팀원들과 공유해야 원활히 해결할 수 있다. 안그러면 더 꼬인다.

---

결론

이번 경험을 통해, 깃 복구 작업은 단순한 명령어 실행 이상의 세심한 주의와 확인 과정을 요구한다는 것을 알게 되었다. 특히 백업, 저장(커밋)의 중요성, 브랜치 생성, 그리고 충돌 해결 시의 꼼꼼한 검증은 앞으로 깃을 사용할 때 꼭 기억해야 할 부분이다.

 

🔗참고 링크 : https://docs.github.com/ko/desktop/managing-commits/reverting-a-commit-in-github-desktop

GitHub Desktop에서 커밋 되돌리기 - GitHub Docs