기능브랜치에서 열심히 작업한 내용을 push하려하니 원격에서 pull할게 있다고 해서 pull을 했다.
근데 내가 작업하던게 다 날라갔다...
이것밖에 없을리가 없어...
며칠동안 작업한게 다 날아간걸 확인하고, git log에도 그동안 열심히 커밋했던게 싹 사라지고 원격에 있던것만 남아있는걸 보고 순간 멘탈이 붕괴되었다가 검색을 통해 해결할 수 있는 방법이 있다는걸 알게됬다.
push하기 전에 commit을 해놓았다면 git reflog를 통해 pull 전의 모든 커밋기록까지 확인할 수 있다.
맨 위에서 두번 째, 90d8e92 이름의 커밋이 내가 마지막으로 작업하고 커밋했던 내용이고.
맨 위에있는 9d0c591 이름의 커밋이 내가 원격에서 pull을받느라 내 작업을 다 없애버린 커밋이다.
일단 침착한다. (1번)
내가 돌아가고싶은 커밋 번호를 확인한 다음, git reset --hard (돌아가고싶은 커밋번호) 를 입력해준다.
그럼 head는 이제 90d8e92, 내가 마지막에 작업했던 커밋에 향하게 된다. (살았다 ㅜㅜ)
다시 작업하던 브랜치고 가려고했더니 그 전에 pull받은게 rebase중으로 잡혀있어서 rebase를 quit하라고 한다.
git rebase --quit을 해 주었다.
내 브랜치로 잘 넘어왔다..
알고보니 git push origin develop으로 push를 해서 생긴 문제였다.
내 기능브랜치에서 -> 원격의 develop으로 바로 push를 하려면 원격 develop의 최신상태가 내 로컬에 다 있어야지만 그 위에 커밋을 쌓고 push가 가능한데 그렇지 않아서 pull을 먼저 하라고 하는건 당연한거다.
나는 원격에 있는 '기능브랜치'에 먼저 push를 해 준다음 develop으로 pr을 날려야 하는 상황이었다.
어디서 작업을 하고 어디로 무엇을 보내고 pr날려야하는지 명심해야겠다. ㅠㅠ 십년감수
커밋 로그 확인
git reflog
혹은
git log -g
커밋 시점으로 되돌리기
git reset --hard [commit_id]
'Front-End Developer > Computer Science' 카테고리의 다른 글
SEO(검색엔진 최적화) : 구글검색엔진에게 간택받기 위한 프로미스 101 (0) | 2022.06.27 |
---|---|
깃 커밋 템플릿 만들어서 간편하게 커밋해보자! (1) | 2022.06.22 |
규모가 크지 않은 팀프로젝트의 git-flow전략(+인프런 강의영상) (0) | 2022.06.21 |
면접관님: 메세지 큐와 이벤트루프가 뭔지 아시나요? (+ 유투브) (2) | 2022.06.15 |
면접관님: 브라우저 렌더링 과정을 설명해보시겠어요?(+유투브) (0) | 2022.06.15 |