일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- awscloudclubs
- 프로젝트
- mysql
- 보안
- IP
- ERD
- 백엔드프로젝트
- 프로토콜
- TCP/IP
- 대용량트래픽
- github
- node
- 클라우드
- javascript
- TCP
- 환경변수
- AWS
- 위코드
- 스프링부트
- 정보처리기사
- Amazon
- 피드시스템
- express
- 네트워크
- wecode
- 알고리즘
- CS
- 가상스레드
- ACC
- cloudclubs
- Today
- Total
아무튼!
[Git/Github] git push origin -f 강제 푸시 후 사라진 커밋 복구하기 본문

git push origin -f main 커밋 되살리기
사족이 깁니다.
해결과정은 맨 아래에 요약해 두었습니다.
깃허브에 푸시를 해야 할 일이 생겼는데
그날따라 왜 pull 없이 push가 하고 싶었을까...
너무 오만했던 나머지
git 님께서 오류 메시지로 구원의 손길을 내밀어 주시던 걸, 뿌리치고 강제 푸시를 해버렸다
정말 오류 메시지는 찬찬히 읽고 최대한 해결하자!!
나의 경우에는
git add .
git commit -m ""
진행 과정에서
변경 사항들 중 일부가 작업 테이블에 올라가지 않아서 나던 오류가 있었다.
하지만 앞에서도 말했듯이 그날따라 오류 메시지가 읽기 귀찮았고
git push -f origin main
을 해버린 것이었다...본인의 뼈대 브랜치 명이 master인 경우에는 main -> master로 대입하여 읽어주시길 바랍니다.
레포를 대충 봤을 때에는 매우 만족스러웠다.
있어야 할 파일들이 모두 있었고
변경사항들도 잘 반영되었다.
남아있는 커밋 개수를 보기 전까지는.
강제성 푸시 후,
이전까지 해당 레포에 기록되던 커밋들이
전부 사라져 버렸다 하하,,...하ㅏ핳...하하하하...

나 혼자만 사용하는 레포였어도 충격적인 상황이었을 텐데
협업하는 레포였어서 정말
있지도 않은 시말서를 제출해야 할 것만 같은 기분이었다.
그렇게 낙담하던 차에 갑자기
푸시 전 상태의 레포를 로컬에 클론 해둔 것이 기억이 났다!
허겁지겁 편집기에서 새로운 윈도우를 띄워
레포를 열고
git log
를 해보니
커밋이 몇 없다..?(경우에 따라 커밋이 없을 수도 있음)
는 터미널에서 파일경로를 아직 덜 들어가서 그런 거였다 ^^..휴
cd 파일명
으로 올바른 경로로 이동한 뒤에
다시 로그를 확인해 보니
이전 커밋들이 남아있었다!!
좀 더 자세히 알고 싶어서
git reset이나 git rebase로
취소하거나, 새롭게 설정한 작업들까지 확인 가능한
git reflog
명령어를 실행해 보니 정말 모든 커밋들이 남아있는 것을 확인할 수 있었다.
로그 조회하면서
이쪽 신, 저쪽 신 등등
온갖 대상들에게 내 삶에 전무후무한 기도를 한 것 같다 하핳
아무튼 오늘의 나는 믿을 것이 못 된다는 판단 하에
혹시 모를 대참사를 대비하여
커밋들이 살아있는 파일을 복제해 두고
작업을 시작했다.
우선
git pull origin main
로 원격 레포를 로컬에 받아왔다.
그리고 변경사항들로 인해 발생한 충돌들을 해결해 줬다.
conflict 해결 후 조회한 로그들에도
이전 커밋을 포함하여 모든 커밋들이 남아있음을 확인했다.
그리고 다시
git push origin main
을 하니 오류가 발생하지 않았고
깃허브에도 커밋들이 전부 복구되어 있는 것을 확인하였다!
사실 "복구"보다는 "덮어씌웠다"라는 표현이 더 맞을 것 같다.
아무튼 그리하여 나는 행복하게 오래오래 살 수 있었다고 한다^.^
이번 대참사를 겪으며
아래의 깨달음을 얻을 수 있었다.
- 강제성 작업(-f 옵션 등)은 정말 위험하다.
- 강제 푸시를 하면 이전 커밋들이 전부 날아간다.
- main으로 직접 푸시하는 일은 지양하자.
main으로 직접 푸시하며 작업하다 보니
브랜치를 나누어서 작업했을 때에 비해
나의 코드와 변경사항들을 체크할 기회가 적어졌고,
이것이 이번 대참사의 원인들 중 하나가 되었다.
사실 버전 관리를 소홀히 할 거면
git을 쓰는 이유가 많이 희미해진다.
변경사항 추적을 용이하게 하기 위해서라도
브랜치를 나누어 작업하고
pr을 작성하여 기록을 남기도록 하자
<요약>
*로컬에 push 이전 상태의 원격 레포 클론파일 필요*
1. 클론 해두었던 레포 파일을 복제한다.(혹시나 하는 마음에)
2. 편집기에서 클론 해뒀던 파일을 연다.
3. git pull origin main 후 발생한 충돌 해결
4. git push origin main
'Project > Error.log' 카테고리의 다른 글
[JMeter] Mac M1 jmeter 실행 시 No such file or directory 오류 해결 방법 (0) | 2024.02.20 |
---|---|
[AWS] 서버에 올린 애플리케이션 환경 변수 설정하기 (0) | 2024.02.07 |