왜 알아야 할까
잘못된 reset 복구: 정상처럼 보이는 한 사례만으로는 동작 범위를 이해하기 어렵습니다. 대표 입력에서는 문제없다가 경계값, 느린 응답, 배포 직후처럼 조건이 달라질 때 결과가 바뀔 수 있습니다.
reset 뒤 commit이 branch에서 사라져도 object가 정리되기 전에는 reflog에서 이전 HEAD를 찾아 새 branch로 보존할 수 있습니다.
동작을 나누어 보기
commit graph, index, working tree와 remote reference로 구성된 Git 저장소에서 어느 경계가 결과를 결정하는지 먼저 봅니다. working tree, index와 commit graph 중 어디가 예상과 다른지 먼저 나눕니다. 명령을 실행하기 전 현재 branch·HEAD와 변경 파일을 확인해야 복구 기준을 잃지 않습니다.
| 구분 | 짧은 예시 |
|---|---|
| 기대 결과 | 잘못된 reset 복구: 정상 조건에서 사용자가 받아야 할 결과 |
| 실제 결과 | 같은 입력에서 처음 달라진 값·상태·오류 |
| 판별 자료 | status, diff, log --graph, reflog와 각 ref가 가리키는 commit을 먼저 확인한다 |
작게 적용하는 방법
공유 이력과 로컬 이력을 구분하고 복구 가능한 ref를 만든 뒤 최소 범위의 비파괴 명령을 선택한다. 공유된 commit과 로컬 변경을 구분하고, 되돌릴 ref를 확보한 뒤 목적에 맞는 가장 작은 Git 명령을 사용합니다.
대표 사례 하나, 값이 달라지는 경계 하나, 예상 가능한 실패 하나를 같은 순서로 확인합니다. 작업 트리, index, commit graph와 remote 차이를 다시 확인하고 필요한 빌드·테스트를 수행한다. git status, 필요한 git diff와 commit graph를 다시 확인하고 새 clone이나 별도 worktree에서도 기대한 history와 파일이 재현되는지 검사합니다.
공식 문서와 적용 범위
문서의 기본값과 동작은 version에 따라 달라질 수 있습니다. 현재 도구 version, repository 상태, 보호 규칙과 협업 절차에서 다시 확인합니다.