어느 날, 내 커밋이 사라졌다.
회사에서 사이드 프로젝트를 시작했다.
레포를 파지 않고, 일단 프론트엔드 먼저 로컬에서 작업을 시작했다.
충분히 작업을 해둔 뒤, 깃허브에 레포를 새로 만들고, remote를 설정했다.
앗차차 생각해보니 모노레포 구조여야 해서, 상위 폴더를 새로 만들고, 기존의 fe 폴더를 옮겨 넣었다.
그러고서 레포를 새로 판 뒤, remote를 설정했다.
이런! ssh로 하니까 push가 안되나보다.
내가 못하는 동안 백엔드 팀원분께서 먼저 백엔드 프로젝트를 넣어주셨다. 끙..
마음이 급해진 나는 그냥 커서에게 맡겼다.
커서는 자동으로 remote를 HTTPS로 변경하고, push를 하려 했다.
근데 로컬 커밋과 충돌이 났고, 이 좌식이 rebase를 갈겨버렸다.
그리고 내 커밋은 몽땅 날아갔다.
여름이었다.
문제 상황
커서를 너무 믿은 나머지.
MCP니 커서룰이니 신세계를 맛본 요즘 이것저것 쓰다보니, 커서에 대한 의존도가 높아지는 나날이었다.
오늘도 마찬가지였다.
SSH로 레포와 연결이 되지 않길래, HTTPS로 바꾸면 될 일이었다.
이마저도 커서에 맡긴 것인데, 커서는 한발 더 나아가 push까지 해주려는 착한 마음에, rebase 를 갈겨버린 것이다.
그렇게 빈 레포가 덮어씌워지는 바람에, 기존 코드가 유실되었다.
위는 기억나는 대로 재구성한 뼈만 앙상하게 남은 프로젝트.. 😢
그래놓고 당당한 모습. 이 매력에 어찌 커서를 사랑하지 않을 수 있나
rebase로 코드가 유실된 이유
rebase 과정에서, 원격 레포에 로컬 레포의 디렉토리가 없다면 유실된다.
해결 이후 문제를 찾는 과정에서 덤으로 알게된 지식이다.
참으로 당당한 녀석의 설명을 보자.
git pull --rebase는 다음과 같이 작동합니다:
1. 원격 변경사항을 가져옵니다 (git fetch)
2. 로컬 변경사항을 임시로 제거합니다
3. 원격 변경사항을 적용합니다
4. 로컬 변경사항을 원격 변경사항 위에 다시 적용합니다
문제는 원격 저장소에fe디렉토리가 없었다는 점입니다.
로컬에서는 이 디렉토리가 있었지만, 원격 저장소에는be만 있었을 가능성이 높습니다.
이런 상황에서 리베이스를 실행하면, Git은 원격 저장소의 상태를 기준으로 삼기 때문에fe디렉토리가 삭제된 것으로 처리됩니다.
거 참 옛날부터 깃은 디렉토리 대소문자도 헷갈리고
손가는 게 많은 친구더라.
해결 과정
휴지통에서 발견한 한줄기 빛
그러다가, 휴지통에서 따끈따끈한 .git 디렉토리를 발견했다.
삭제한 기억은 없었는데, 몰라 일단 복구하고 보자.
이놈을 뼈만 앙상하게 남은 fe 디렉토리에 넣고, 로그를 확인했다.
git reflog로 로그를 보자
눈물이 날뻔한 순간.
내 커밋메시지를 두 눈으로 보게 되었다. 흑흑흑흑 감사합니다.
이후 해당 커밋으로 돌리니, 내 코드가 살아 숨쉬는 모습을 확인했다.
인고의 시간을 거쳐 복구에 성공했다.
그리고, 큰 교훈을 얻었다.
Cursor는 코드 퀄리티를 올리는 데에만 쓰자.
특히, git과 같은 민감하고 위험한 부분은 너무 믿지 말자.
