되돌리기 & 복구 실습 예시

AI가 망친 변경을 안전하게 되돌리고 잃은 작업을 복구하는 흐름을 시나리오로 익히는 가이드 | ← 매뉴얼로 돌아가기

대상 Git 버전git 2.5x (2.50.1 기준)

이 파일의 목적매뉴얼을 보완하는 실습·교육용 시나리오 예시집

레퍼런스 문서Undo_Manual.html — 각 시나리오에서 링크로 연결됩니다

작성일2026년 6월 16일

● 초급 가벼운 되돌리기 아직 커밋 전인, 가장 흔하고 안전한 되돌리기

G-1 초급 잘못 add 한 것을 커밋 전에 취소하기

AI에게 기능 추가를 맡긴 뒤 git add .로 전부 스테이징했습니다. 그런데 AI가 함께 만든 임시 메모 파일 notes.txt까지 커밋 후보에 올라갔습니다. 파일 내용은 그대로 두고 이번 커밋에서만 빼고 싶습니다.

사용 요소

git status git restore --staged

단계별 실행

스테이징 목록 확인
status에 'Changes to be committed'로 올라온 파일을 봅니다. 빠질 파일이 거기 있는지부터 확인합니다.
```
git status
```

해당 파일만 스테이징에서 내리기

수정 내용은 보존하고 add만 취소합니다. 파일은 다시 '변경됨' 상태로 내려옵니다.

git restore --staged notes.txt   # 스테이징에서만 내림(내용은 그대로)
git status                        # notes.txt는 다시 '변경됨'으로 내려옴

나머지만 커밋
의도한 파일만 깔끔하게 커밋합니다.
```
git commit -m "기능 구현 (메모 파일 제외)"
```

git restore --staged <파일>은 git reset <파일>과 똑같은 '스테이징 취소'입니다. 파일의 수정 내용은 전혀 건드리지 않고, add로 올렸던 것만 되돌립니다. --staged가 붙으면 안전하고, 안 붙은 git restore notes.txt는 작업 폴더의 수정 자체를 지우니 헷갈리지 마세요.

스테이징한 것을 전부 한 번에 내리려면 git restore --staged .처럼 점을 씁니다. AI가 한꺼번에 add한 변경을 다시 골라 담을 때 유용합니다.

● 중급 공유된 커밋 안전하게 되돌리기 이미 push해 남과 공유된 커밋을 이력을 보존한 채 취소하는 단계

D-1 중급 이미 push한 커밋을 안전하게 되돌리기 (revert)

어제 AI와 만든 커밋을 GitHub에 push했는데, 그 변경이 버그를 일으킨다는 것을 동료가 발견했습니다. 이미 공유된 커밋이라 이력을 지울 수는 없고, 그 변경만 안전하게 취소하고 싶습니다.

사용 요소

git log --oneline git revert <커밋>

단계별 실행

되돌릴 커밋 ID 찾기
log --oneline으로 문제 커밋의 앞 7자리 해시를 확인합니다.
```
git log --oneline
```
그 커밋을 되돌리는 새 커밋 만들기
revert는 변경을 거꾸로 적용하는 새 커밋을 추가합니다(이력은 보존).
```
git revert a1b2c3d           # 해당 커밋을 되돌리는 '새 커밋' 생성
```
되돌림 커밋을 push
팀과 충돌 없이 변경이 취소됩니다.
```
git push
```

revert는 커밋을 지우지 않고, 그 변경을 정반대로 되돌리는 새 커밋을 하나 더 쌓습니다. 그래서 이력이 그대로 남아 누가 봐도 "이 변경을 의도적으로 되돌렸다"는 흐름이 보입니다. push해 공유된 커밋은 이렇게 revert로 되돌려야 합니다.

이미 push해 공유된 커밋에는 git reset --hard나 git push --force를 쓰지 마세요. 내 쪽 이력만 지워지고 남들의 이력과 어긋나 충돌이 납니다. 공유된 변경의 취소는 언제나 revert입니다. reset은 push 전 커밋에만 씁니다.

● 고급 잃은 것 복구하기 사라진 듯한 커밋을 reflog로 되살리는 응급 복구 단계

P-1 고급 reset --hard 실수를 reflog로 응급 복구하기

AI가 만든 커밋들을 정리하다가 git reset --hard를 잘못 실행해, 멀쩡하던 커밋 몇 개가 사라진 것처럼 보입니다. git log에도 안 보여 식은땀이 납니다. 다행히 이 커밋들은 push 여부와 상관없이 로컬에 흔적이 남아 있습니다.

사용 요소

git reflog git reset --hard HEAD@{n}

단계별 실행

과거 HEAD 위치 목록 보기
reflog는 HEAD가 거쳐 간 지점을 HEAD@{0}, HEAD@{1}… 식으로 보여 줍니다.
```
git reflog                       # HEAD@{0}, HEAD@{1} ... 목록 확인
```
되돌리고 싶은 지점 찾기
reset 직전, 즉 커밋이 멀쩡하던 시점의 항목을 고릅니다. commit: ...으로 끝나는 줄이 보통 그 지점입니다.
그 지점으로 복구
reset --hard HEAD@{n}으로 사라진 커밋들이 되돌아옵니다.
```
git reset --hard HEAD@{2}        # reset 직전 지점으로 복구
```

reset --hard로 커밋을 잃은 것처럼 보여도, Git은 HEAD가 움직인 기록을 reflog에 한동안 남겨 둡니다. 그래서 reset 직전의 HEAD@{n}을 찾아 그 지점으로 다시 reset --hard하면 사라진 커밋을 되살릴 수 있습니다. git log에는 안 보이는 커밋도 reflog에는 남아 있는 경우가 많습니다.

복구에 쓰는 명령도 reset --hard라 그 자체가 파괴적입니다. 잘못 짚으면 또 다른 상태를 덮어쓸 수 있으니, 실행 전 reflog 목록에서 번호를 신중히 확인하세요. 또한 reflog는 로컬 전용이라 다른 컴퓨터에서 복제한 저장소에는 이 기록이 없습니다.

정말 위험한 정리 작업 전에는 미리 git branch backup으로 현재 지점에 이름표를 달아 두면, reflog를 뒤질 필요 없이 git reset --hard backup으로 바로 복귀할 수 있습니다.

git 2.5x(2.50.1) 기준 | 2026년 6월 16일 작성
← 되돌리기 & 복구 매뉴얼 | Git 기초 실습 →