git rebase 중에 충돌을 잘못 풀었더니 커밋 하나가 통째로 사라졌어요

Question

피처 브랜치를 main 위로 rebase 하다가 충돌이 세 군데 났는데, 정신없이 풀다가 한 파일은 그냥 <<<< 마커째 지워버리고 git add . 하고 rebase --continue 를 눌렀습니다.

rebase는 끝났는데 로그를 보니 어제 작업한 커밋 하나(로그인 리팩터링)가 통째로 안 보여요. git log에 아예 없습니다. 파일 내용도 그 변경분만 사라진 상태고요.

혹시나 해서 git reflog는 봤는데 줄이 너무 많아서 어떤 게 그 커밋인지 못 찾겠습니다. 강제로 뭘 잘못 눌러서 완전히 날아간 걸까요? 아직 push는 안 한 로컬 브랜치입니다.

$ git status
On branch feature/login
nothing to commit, working tree clean
$ git log --oneline -5
a1c3f92 (HEAD -> feature/login) fix form validation
7e0b18d update deps
...

김영삼 · Accepted Answer

아직 push 안 했어도, 그리고 rebase에서 커밋이 log에 안 보여도, 그 커밋 객체 자체는 최소 30일(reflog expire 기본값)은 살아있습니다. 완전히 날아간 게 아니니 일단 안심하세요.

reflog가 길어서 못 찾겠다고 하셨는데, 줄을 눈으로 훑지 말고 잃어버린 커밋을 직접 찾으세요. 어디에도 안 붙은 커밋은 git fsck --no-reflogs --lost-found 하면 dangling commit으로 뜹니다. 거기 나온 sha를 git show 로 하나씩 열어보면 '로그인 리팩터링' 커밋이 그 안에 있을 겁니다.

찾았으면 복구는 두 갈래예요. 그 커밋 하나만 필요하면 git cherry-pick 으로 지금 HEAD 위에 얹으면 되고, rebase 자체가 통째로 이상해진 거면 rebase 하기 직전 상태가 reflog에 남아있으니 그걸 git reset --hard 로 되돌리는 게 낫습니다. reflog에서 'rebase (start)' 바로 윗줄 sha가 rebase 시작 전 상태입니다.

다음부터 충돌 풀 때 마커째 지우는 사고 막으려면, add 하기 전에 git diff --check 를 한 번 돌리세요. 남아있는 충돌 마커를 잡아줍니다.

rebase_jaehwan · Answer

감사합니다. fsck로 그 커밋 sha는 찾았는데요, cherry-pick 하니까 지금 HEAD 위에 또 충돌이 납니다. 이건 그냥 다시 풀면 되는 건가요? 아니면 reset --hard로 rebase 전체를 되돌리는 게 더 나을까요?

김영삼 · Answer

그 커밋 하나만 살리려던 게 아니라 rebase 결과 전체가 이상한 거면, cherry-pick 충돌 붙잡고 씨름하지 말고 abort 하고 rebase 전으로 통째로 되돌리는 걸 추천합니다. reflog에서 reset --hard 하는 방식이요.

cherry-pick에서 나는 충돌은 지금 HEAD랑 그 커밋이 같은 파일을 건드려서 나는 정상적인 충돌이라 데이터가 깨진 건 아닙니다. 다만 rebase 전체를 되돌릴 거면 그 cherry-pick은 의미가 없어지니 git cherry-pick --abort 가 맞아요.

되돌린 다음 rebase를 다시 하되, 충돌 파일이 많으면 한 번에 몰아 풀지 말고 커밋마다 멈출 때 천천히 푸시고, continue 전에 아까 말한 diff --check 를 습관으로 돌리세요.

rebase_jaehwan · Answer

reset --hard 로 rebase 전으로 돌아가니 사라졌던 커밋 그대로 있네요. 살았습니다 🙏 diff --check 도 앞으로 꼭 쓸게요.

댓글 4