되돌리기·복구 실습 예시

실수했을 때 안전하게 되돌리고 복구하는 흐름을 시나리오로 익히는 가이드  |  ← 매뉴얼로 돌아가기

대상 Git 버전2.40 이상 (최신 2.54.0 기준)
이 파일의 목적매뉴얼을 보완하는 실습·교육용 시나리오 예시집
매뉴얼 문서Undo_Recovery_Manual.html — 각 시나리오에서 링크로 연결됩니다
작성일2026년 6월 13일
● 초급 가벼운 되돌리기 아직 커밋 전이거나 방금 한 커밋을 고치는, 가장 흔한 되돌리기
G-1 초급 방금 한 수정을 통째로 되돌리기
style.css를 이것저것 고쳐봤는데 결과가 더 나빠졌습니다. 저장은 했지만 아직 커밋도, add도 하지 않았습니다. 마지막 커밋 상태로 이 파일을 깨끗이 되돌리고 싶습니다.
사용 명령어
단계별 실행
  1. 무엇이 바뀌었는지 먼저 확인

    status로 수정된(아직 커밋 안 된) 파일을 봅니다.

  2. 해당 파일을 마지막 커밋 상태로 되돌리기

    restore가 작업 폴더의 수정 내용을 버리고 원래대로 맞춥니다.

  3. 되돌려졌는지 확인

    다시 status를 치면 변경 사항이 사라져 있습니다.

git status
git restore style.css      # 저장한 수정 내용이 사라지고 마지막 커밋 상태로 복귀
git status                 # 더 이상 변경 없음
git restore <파일>로 버린 수정은 되살릴 수 없습니다. 저장만 하고 add·commit 하지 않은 변경이라면 Git이 기록을 갖고 있지 않기 때문입니다. 실행 전에 정말 버려도 되는 변경인지 한 번 더 확인하세요.
파일 전체가 아니라 일부 변경만 살리고 싶다면, 먼저 살릴 부분을 따로 복사해 두거나 에디터의 실행 취소를 활용하세요. restore는 파일 단위로 통째 되돌립니다.
G-2 초급 잘못 add 한 것을 커밋 전에 취소하기
git add .을 했는데, 이번 커밋에는 넣고 싶지 않은 notes.txt까지 스테이징됐습니다. 파일 내용은 그대로 두고 '커밋 후보'에서만 빼고 싶습니다.
사용 명령어
단계별 실행
  1. 스테이징 목록 확인

    status에 'Changes to be committed'로 올라온 파일을 봅니다.

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

    수정 내용은 보존하고 add만 취소합니다.

  3. 나머지만 커밋
git status
git restore --staged notes.txt   # 스테이징에서만 내림(파일 내용은 그대로)
git status                        # notes.txt는 다시 '변경됨'으로 내려옴
git commit -m "본 작업 커밋"
git restore --staged <파일>git reset <파일>과 똑같은 '스테이징 취소'입니다. 파일의 수정 내용은 전혀 건드리지 않고, add로 올렸던 것만 되돌립니다. G-1의 git restore(작업 폴더 되돌리기)와 헷갈리지 마세요. --staged가 붙으면 안전하고, 안 붙으면 수정이 사라집니다.
스테이징한 것을 전부 한 번에 내리려면 git restore --staged .처럼 점을 쓰면 됩니다.
G-3 초급 직전 커밋 메시지를 고치기
방금 git commit -m "수졍"이라고 오타를 낸 채 커밋했습니다. 아직 어디에도 push하지 않았습니다. 메시지를 제대로 고치고, 깜빡하고 빠뜨린 파일도 같은 커밋에 함께 넣고 싶습니다.
사용 명령어
단계별 실행
  1. 메시지만 바로잡기

    --amend -m으로 직전 커밋의 메시지를 새로 씁니다.

  2. (빠뜨린 파일이 있다면) 먼저 add

    빠진 파일을 스테이징한 뒤 amend 하면 같은 커밋에 합쳐집니다.

  3. amend로 합치기

    -m 없이 git commit --amend를 실행하면 에디터가 열려 메시지를 재확인·수정할 수 있습니다. (1단계처럼 -m을 붙이면 에디터를 열지 않고 메시지를 바로 확정합니다.)

# 메시지만 고칠 때
git commit --amend -m "회원가입 폼 검증 추가"

# 빠뜨린 파일까지 같은 커밋에 넣을 때
git add forgotten.js
git commit --amend           # 에디터에서 메시지 확인 후 저장
--amend는 직전 커밋을 새 커밋으로 갈아치웁니다. 그래서 아직 push하지 않은(공유 전) 커밋에만 쓰세요. 이미 push해 남들이 받아 간 커밋을 amend 하면 이력이 어긋나 협업에 충돌이 생깁니다.
● 중급 커밋을 다루고 작업을 치워두기 커밋을 풀어 다시 만들고, 작업을 임시 보관하고, 공유된 커밋을 안전하게 되돌리는 단계
D-1 중급 마지막 커밋을 풀어서 다시 하기 (soft)
방금 커밋하고 보니 커밋 단위가 어설펐습니다. 변경 내용은 그대로 두되, 커밋만 풀어서 스테이징 상태로 되돌린 다음 더 나은 단위로 다시 커밋하고 싶습니다. 아직 push 전입니다.
단계별 실행
  1. 마지막 커밋 1개를 풀기

    reset --soft HEAD~1로 커밋만 풀고 변경은 스테이징에 남깁니다.

  2. 스테이징 상태 확인

    status에 변경이 'Changes to be committed'로 남아 있는지 봅니다.

  3. 원하는 메시지로 다시 커밋
git reset --soft HEAD~1     # 마지막 커밋만 풀기(변경은 스테이징에 보존)
git status                  # 변경이 '커밋 대기'로 남아 있음
git commit -m "회원가입 기능 구현 (폼·검증·에러 처리)"
reset은 세 가지 모드가 있습니다. --soft는 HEAD만 옮겨 커밋을 풀고 변경은 스테이징에 그대로 둡니다. 기본값인 --mixed는 HEAD와 인덱스(스테이징)를 되돌려 변경이 '아직 add 안 된' 상태로 내려옵니다. --hard는 작업 폴더까지 전부 되돌려 변경 자체를 지웁니다. 최근 3개를 합치려면 HEAD~3처럼 숫자를 늘립니다.
--hard는 작업 폴더의 변경까지 지우는 파괴적 명령입니다. 이 시나리오에서는 변경을 살려야 하므로 반드시 --soft를 쓰세요. 그리고 reset으로 이력을 고치는 작업은 push 전 커밋에만 합니다.
D-2 중급 작업을 잠깐 치워두고 급한 일 처리하기 (stash)
새 기능을 절반쯤 만들던 중에 "지금 당장 운영 버그부터 고쳐라"는 요청이 왔습니다. 지금 변경은 커밋하기엔 미완성이라, 잠시 안전하게 치워두고 작업 폴더를 깨끗이 만든 뒤 급한 일을 처리하려 합니다.
단계별 실행
  1. 지금 작업을 임시 보관

    git stash가 변경을 따로 저장하고 작업 폴더를 마지막 커밋 상태로 깨끗이 만듭니다.

  2. 급한 일 처리

    깨끗한 상태에서 버그를 고치고 커밋합니다.

  3. 치워둔 작업 되살리기

    git stash pop으로 보관했던 변경을 작업 폴더로 다시 꺼냅니다.

git stash                    # 변경을 임시 저장 + 작업 폴더 깨끗이
# (여기서 급한 버그 수정 → 커밋)
git stash list               # 치워둔 항목 확인: stash@{0} ...
git stash pop                # 되살리고 목록에서 제거
흐름은 이렇습니다. 작업 중 → git stash → 급한 일 처리 → 돌아와서 git stash pop. pop은 보관한 변경을 되살리면서 목록에서 지우고, git stash apply는 되살리되 목록에 그대로 남겨 둡니다. 새로 만든(아직 추적 안 된) 파일까지 함께 치우려면 git stash -u를 씁니다.
stash는 여러 개를 쌓을 수 있습니다. git stash liststash@{0}, stash@{1} 식으로 확인하고, 특정 항목을 꺼내려면 git stash pop stash@{1}처럼 번호를 지정하세요.
D-3 중급 이미 push한 커밋을 안전하게 되돌리기 (revert)
어제 만든 커밋을 GitHub에 push했는데, 그 변경이 버그를 일으킨다는 것을 동료가 발견했습니다. 이미 공유된 커밋이라 이력을 지울 수는 없고, 그 변경만 안전하게 취소하고 싶습니다.
단계별 실행
  1. 되돌릴 커밋 ID 찾기

    log --oneline으로 문제 커밋의 앞 7자리 해시를 확인합니다.

  2. 그 커밋을 되돌리는 새 커밋 만들기

    revert는 변경을 거꾸로 적용하는 새 커밋을 추가합니다(이력은 보존).

  3. 되돌림 커밋을 push

    팀과 충돌 없이 변경이 취소됩니다.

git log --oneline
git revert a1b2c3d           # 해당 커밋을 되돌리는 '새 커밋' 생성
git push
revert는 커밋을 지우지 않고, 그 변경을 정반대로 되돌리는 새 커밋을 하나 더 쌓습니다. 그래서 이력이 그대로 남아 누가 봐도 "이 변경을 의도적으로 되돌렸다"는 흐름이 보입니다. push해 공유된 커밋은 이렇게 revert로 되돌려야 합니다.
이미 push해 공유된 커밋에는 git reset --hard를 쓰지 마세요. 내 쪽 이력만 지워지고 남들의 이력과 어긋나 충돌이 납니다. 공유된 변경의 취소는 언제나 revert입니다. reset은 push 전 커밋에만.
● 고급 잃은 것 복구하고 위험 작업 대비하기 사라진 듯한 커밋을 reflog로 되살리고, 위험한 정리 전에 안전망을 깔아 두는 단계
P-1 고급 reset --hard 실수를 reflog로 복구하기
커밋들을 정리하다가 git reset --hard를 잘못 실행해, 멀쩡하던 커밋 몇 개가 사라진 것처럼 보입니다. git log에도 안 보여 식은땀이 납니다. 다행히 이 커밋들은 push 여부와 상관없이 로컬에 흔적이 남아 있습니다.
단계별 실행
  1. 과거 HEAD 위치 목록 보기

    reflog는 HEAD가 거쳐 간 지점을 HEAD@{0}, HEAD@{1}… 식으로 보여 줍니다.

  2. 되돌리고 싶은 지점 찾기

    reset 직전, 즉 커밋이 멀쩡하던 시점의 항목을 고릅니다.

  3. 그 지점으로 복구

    reset --hard HEAD@{n}으로 사라진 커밋들이 되돌아옵니다.

git reflog                       # HEAD@{0}, HEAD@{1} ... 목록 확인
git reset --hard HEAD@{2}        # reset 직전 지점으로 복구
reset --hard로 커밋을 잃은 것처럼 보여도, Git은 HEAD가 움직인 기록을 reflog에 한동안 남겨 둡니다. 그래서 reset 직전의 HEAD@{n}을 찾아 그 지점으로 다시 reset --hard하면 사라진 커밋을 되살릴 수 있습니다. git log에는 안 보이는 커밋도 reflog에는 남아 있는 경우가 많습니다.
복구에 쓰는 명령도 reset --hard라 그 자체가 파괴적입니다. 잘못 짚으면 또 다른 상태를 덮어쓸 수 있으니, 실행 전 reflog 목록에서 번호를 신중히 확인하세요. 또한 reflog는 로컬 전용이라 다른 컴퓨터에서 복제한 저장소에는 이 기록이 없습니다.
P-2 고급 백업 브랜치를 두고 위험한 정리 작업 하기
여러 커밋을 합치고 풀어내는 큰 정리 작업을 앞두고 있습니다. 중간에 무언가 꼬여도 즉시 지금 상태로 되돌아올 수 있도록, 작업 전에 안전망을 만들어 두려 합니다.
단계별 실행
  1. 현재 상태에 백업 라벨 달기

    git branch backup-...으로 지금 커밋에 브랜치 이름을 남겨 둡니다.

  2. 안심하고 위험한 정리 작업 진행

    꼬여도 백업 브랜치가 원래 지점을 가리키고 있습니다.

  3. 잘못되면 백업으로 복귀

    switch로 백업 브랜치로 돌아가거나, 현재 브랜치를 백업 지점으로 되돌립니다.

# 1) 위험 작업 전 현재 상태에 라벨
git branch backup-2026-06-13

# 2) (여기서 reset/정리 작업 진행)

# 3) 꼬였을 때 복귀: 백업 브랜치로 이동
git switch backup-2026-06-13

#    또는 현재 브랜치를 백업 지점으로 되돌림
git reset --hard backup-2026-06-13
git branch backup-...은 새 작업 없이 지금 커밋에 이름표만 붙입니다. 비용도 위험도 없는 안전망입니다. 작업이 꼬이면 git switch backup-...로 그 지점으로 옮겨 가거나, 현재 브랜치를 백업 지점으로 reset --hard해 원상복구할 수 있습니다. 정리가 잘 끝났다면 백업 브랜치는 git branch -d로 지워도 됩니다.
3단계의 git reset --hard backup-...은 현재 브랜치의 이후 작업을 전부 버리는 파괴적 명령입니다. 정말 백업 지점으로 되돌릴 의도가 맞는지 확인하고 실행하세요. 그래도 실수했다면 P-1reflog로 복구를 시도할 수 있습니다.

Git 2.54.0 기준 · 2026년 6월 13일 작성
📖 되돌리기 매뉴얼 →  |  Git 기초 실습 →