오늘 파이썬 코드 작업 도중 git에 올려야 하는 코드를 제외하고 commit메시지를 작성하였다.
commit을 취소 하기 위해
git reset --hard HEAD^
를 입력하여 commit을 취소하고 다시 git add 를 실행하는데 Nothing to Commit이라고
출력이 되었다. 다시 깃허브 명령어를 보니 --soft 옵션이 아니고 --hard옵션으로 실행되어
commit이 취소되는 동시에 해당 파일들은 예전 코드로 변경이 되어 있었다.
흘려본적 없는 식은땀이 났고, 고객사에 제출해야하는데 코드가 모두 날아가서 매우 당황스러웠다.
git-scm을 찾아서 되돌릴 방법을 찾아 본 결과 획기적인(그 당시의 나에게만) 명령어가 있었다.
그 명령어는 다음과 같다.
SYNOPSIS
git reflog <subcommand> <options>
SUBCOMMAND & OPTIONS
git reflog [show] [log-options] [<ref>]
git reflog expire [--expire=<time>] [--expire-unreachable=<time>]
[--rewrite] [--updateref] [--stale-fix]
[--dry-run | -n] [--verbose] [--all [--single-worktree] | <refs>…]
git reflog delete [--rewrite] [--updateref]
[--dry-run | -n] [--verbose] ref@{specifier}…
git reflog exists <ref>
위 documentation을 보고 git reflog을 입력하니 다음과 같이 메시지가 출력이 되었다.
다행히 내가 날려먹은 커밋 기록인 "debug on amazon linux_20191126"이 존재하였고,
해당 HEAD로 파일들을 reset시켜 기록을 되돌려 놓을 수 있었다.
이참에 git reset의 --hard, --soft, --mixed옵션에 대해서 한번 다시 공부하기로 하였다.
옵션을 표로 정리해 보았다.
| index | staged / unstaged | 작업 중이던 파일 | |
| git reset --hard | 해당 index 취소 | unstaged로 변경 | 작업 취소(유실) |
|
git reset --mixed (Default option) |
해당 index 취소 | unstaged로 변경 | 작업 보존 |
| git reset --soft | 유지 | staged 상태 유지 | 작업 보존 |
이 표로 정리하고 나니, 내가 식은 땀을 흘렸던 상황이었을 때 git reset -mixed를 사용하여
commit을 취소하고, 작업은 살리는 쪽으로 했어야 했었다.
다시는 이런 실수 안하겠지...