사건의 발단
진행 중이던 프로젝트의 브랜치 이름들이 올바르게 생성되어 있지 않아서 수정하려고 했다.
하지만 모든 브랜치들이 수정되고 삭제되는 과정으로인해 로컬에 있던 브랜치와 원격 브랜치들이 맞지 않았다.
결국 로컬에 있는 코드를 삭제하고 다시 clone을 하는 과정을 진행했다.
하지만 mac book을 오랜만에 켜서 그런진 모르겠지만... Intelij에서 GitHub 연동이 되지 않아 난감했다.
이러면 안됐지만 ..!
그냥 Fork도 다시 해보자는 생각에 레포지토리를 삭제 해버렸다.
그런데.....
삭제하고 생각해보니 왜 레포지토리 앞에 내 이름이 아닌 Organization이 들어있지? 라는 생각이 슥 스쳤다.
아 큰일 났다. X 됐다.
이미 일은 저질러진 것이었음을...
이때 백엔드 팀 회의를 하면서 작업하고 있었어서 팀원 분들께 바로 알렸다.
사건의 해결 과정
결론부터 말하자면, 생각보다 빨리 복구되었다.
식은 땀과 함께 구글링을 했고, 아래의 방법들을 사용했다.
- Organization Owner라면 복구가 가능하다?
- 빠르게 Owner 권한을 가진 분을 불러 조치하려 했지만 1-2시간이 지나도 레포지토리 지운 내역이 생기지 않았다.
- GitHub 측에 지원 티켓 만들기
- 취업 때문에 이력서에 올라가 있는 깃허브 주소였기에 빠른 복구가 절실해서 최대한 절박한 내용을 담아 적었다.
- 혹시 몰라서 팀원 중 github pro 계정인 팀원에게 부탁했다.
엄청 오래 걸린다는 얘기를 듣고 무서웠지만 GitHub 측에서 문의를 빨리 대응 해주셔서 티켓 요청한지 한 30분도 안되어 복구되었다.
사건의 결과
사실 코드 자체는 최신 코드로 fork 되어있는 레포지토리도 있었기 때문에 코드 자체는 괜찮았지만, 몇 개월 동안 쌓아온 PR과 Issue들이 복구되지 않을까봐 노심초사 했다.
확인해보니 PR과 Issue들도 모두 돌아왔지만 레포지토리가 Fork된 레포지토리의 Fork로 뜨는 것이었다.
해당 페이지에 sync에 대한 부분이 아래에 떴기 때문에 신경쓰여서 fork 해갔었던 기존 레포지토리를 삭제 해도 괜찮을지 테스트하고 삭제 하기로 했다.
테스트 과정은 다음과 같다.
GitHub에서 원본 레포지토리 A가 있다고 가정했을 때,
B: A 레포지토리를 포크
C: A 레포지토리를 삭제하고 B 레포지토리를 A와 동일한 이름으로 만든 레포지토리
B 레포지토리를 삭제했을 때
원본 리포지토리와 동일한 이름으로 재 fork가 가능한 것을 보고 동일한 방법으로 다시 진행하여 완전한 Organization 복구를 할 수 있었다.
다음부터는 위험한 일을 할 때는 꼭 다른 사람과 함께 하도록, 1번 2번 확인하고 할 수 있도록 하겠습니다..
감사합니다. Git Hub ‼‼👍
'프로젝트 > 프로젝트 과정' 카테고리의 다른 글
[실패] AWS Lambda 환경에서 Ollama를 이용한 코드 리뷰 봇 만들기 (2) | 2024.09.03 |
---|---|
[잔디일기] 랜덤 값 만들기 (0) | 2024.07.28 |
[잔디일기] 에러 핸들링 하기 (0) | 2024.05.24 |
[잔디일기] 코드 리팩토링을 해보자 (0) | 2024.05.22 |
[잔디일기] 패키지 구조에 대한 고민 - 적용결과 (0) | 2024.05.21 |