기능브랜치에서 열심히 작업한 내용을 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]
'삽질기록' 카테고리의 다른 글
0이 서버로 보내지지 않았던 엄청난 이유..! (0) | 2022.07.23 |
---|---|
같은 파일을 선택하면 onChange가 일어나지 않는 이유는? (0) | 2022.07.23 |
리액트 Portal로 깔쌈하게 모달창 구현하기 (0) | 2022.07.16 |
교차 출처 리소스 공유(CORS)가 뭔데? - 프론트엔드의 숙명 HTTP통신 (0) | 2022.07.14 |
[짜잘한이슈] styled-components 사용시 Invalid hook call 오류 해결하기 (0) | 2022.07.03 |