문제 상황
현재 사용 중인 저장소에는 main 브랜치와 back 브랜치가 있습니다.
back→main병합- 부모 커밋부터 n번째에 있는 커밋 메세지 변경을 위해
main에서git rebase HEAD~n- 명령어 옵션의 의미를 착각해 부모 커밋부터 n번째 커밋까지 모두 재할당
main에 있는 커밋들의 해시 값이 모두 변경돼back의 커밋과 달라짐- 닫힌 이슈들에 동일한 내용의 커밋이 새로운 해시 값으로 다시 push
git rebase HEAD~n의 의미를 "부모 기준으로 n번째까지의 모든 커밋"이 아닌, "부모 기준으로 n번째 커밋"으로 잘못 이해하고 약 20개의 이전 커밋들이 다시 푸시가 되는 사태가 발생했습니다... 😭😭😭
코드 상의 문제는 없었으나... 과거의 커밋이 현재에 다시 push가 되면서
잔디 2배 이벤트 + 브랜치의 변경 내역이 꼬였다는 것이 매우 마음에 걸렸습니다.
한마디로 말하자면, 원격에서 rebase 사용하면 안 된다는 것과 rebase는 커밋을 수정하는 목적이 아니라는 것을 몰라서 생긴 일입니다 ^^!
🚩
git rebase에 대한 설명과 실행 과정은
[Git] Commit 메세지를 수정하는 2가지 방법 (로컬과 리모트)에서 확인할 수 있습니다.
해결
목표
1. 중복 커밋 제거
2.back브랜치의 커밋을main브랜치로 다시 병합
1. 혹시 모를 상황을 대비해 브랜치 백업
1) 로컬에서 back 브랜치의 내용을 backup-back 브랜치로 백업
git checkout -b <백업 할 브랜치>-<새 브랜치 이름>
2) 원격 저장소에 backup-back 브랜치 push (선택)
2. main에서 rebase 하기 전 브랜치의 상태 돌아가기
git reset --hard <hash> : 과거 커밋에 대한 변경 사항을 모두 제거하고 HEAD 포인터를 이전 상태로 이동
- 커밋의 해시는 GitHub에서도 확인 가능하고,
git log --oneline으로 한 줄 씩 출력할 수 있습니다.
3. status 확인
커밋 75개? 🤦♀️ 이게 뭐람 🤷♀️
4. 원격에 로컬의 변경 사항 반영
git push --force
5. back 의 커밋을 main 으로 다시 병합
git cherry-pick <start-commit-hash>^..<end-commit-hash>
- 지정된 커밋의 변경 사항을 현재 브랜치에 복사
- 위 명령어의 옵션은 범위를 지정해 여러 개의 커밋을 한 번에 가져옴
- 이때 변경 사항은 바로 커밋되므로, 별도의 커밋은 필요하지 않음
- 하지만! 🚨 해시 값을 동일하게 복사할 수 없음. 해시는 커밋의 내용과 관련된 고유 식별자이기 때문
와우 ^^..
결과
1. 원격 저장소의 커밋 내역 복구 성공
2. Issue의 커밋 히스토리 제거 실패
새 해시 값으로 중복 푸시되었던 커밋은 제거되지 못했습니다.
Issue에는 커밋을 추가하는 것만 가능하다고 합니다.
참고 자료: 인프런 Q&A-이슈 번호를 잘못 명시한 커밋을 삭제하는 방법
3. 커밋 활동 기록 (잔디) 제거 실패
reset, rebase로 제거된 커밋은 Dangling Commit이 되었고, 원격 저장소에는 약 30일간 보존 후 GC에 의해 삭제된다고 합니다.
그때 잔디도 함께 제거된다고 하니 기다려봐야 알 것 같습니다.
실수했던 날 잘못 푸시한 커밋 개수만 약 40개... GC... 빨리 일해...
마치며
git reset --hard 와 git cherry-pick 을 이용해 중복된 커밋을 제거하는 데 성공했습니다!
Git에서 어떤 이슈가 생기면 일단 등골이 서늘해지고.. 그 이슈를 해결하면서도 긴장되고.. 무섭고.. 저만 그런 거 아니겠죠 🙄
하지만 여러 번의 삽질을 거쳐 Git이 익숙해지니 이보다 편할 수가 없는 것 같습니다.
이렇게 하나 더 배웠다는 것에 감사함과 혼자 쓰는 저장소라서 정말정말정말 다행이라 생각합니다.. 끝!
