되돌리기·복구 실습 예시
실수했을 때 안전하게 되돌리고 복구하는 흐름을 시나리오로 익히는 가이드 | ← 매뉴얼로 돌아가기
style.css를 이것저것 고쳐봤는데 결과가 더 나빠졌습니다. 저장은 했지만 아직 커밋도, add도 하지 않았습니다. 마지막 커밋 상태로 이 파일을 깨끗이 되돌리고 싶습니다.
- 무엇이 바뀌었는지 먼저 확인
status로 수정된(아직 커밋 안 된) 파일을 봅니다. - 해당 파일을 마지막 커밋 상태로 되돌리기
restore가 작업 폴더의 수정 내용을 버리고 원래대로 맞춥니다. - 되돌려졌는지 확인
다시
status를 치면 변경 사항이 사라져 있습니다.
git status git restore style.css # 저장한 수정 내용이 사라지고 마지막 커밋 상태로 복귀 git status # 더 이상 변경 없음
git restore <파일>로 버린 수정은 되살릴 수 없습니다. 저장만 하고 add·commit 하지 않은 변경이라면 Git이 기록을 갖고 있지 않기 때문입니다. 실행 전에 정말 버려도 되는 변경인지 한 번 더 확인하세요.restore는 파일 단위로 통째 되돌립니다.git add .을 했는데, 이번 커밋에는 넣고 싶지 않은 notes.txt까지 스테이징됐습니다. 파일 내용은 그대로 두고 '커밋 후보'에서만 빼고 싶습니다.
- 스테이징 목록 확인
status에 'Changes to be committed'로 올라온 파일을 봅니다. - 해당 파일만 스테이징에서 내리기
수정 내용은 보존하고 add만 취소합니다.
- 나머지만 커밋
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 .처럼 점을 쓰면 됩니다.git commit -m "수졍"이라고 오타를 낸 채 커밋했습니다. 아직 어디에도 push하지 않았습니다. 메시지를 제대로 고치고, 깜빡하고 빠뜨린 파일도 같은 커밋에 함께 넣고 싶습니다.
- 메시지만 바로잡기
--amend -m으로 직전 커밋의 메시지를 새로 씁니다. - (빠뜨린 파일이 있다면) 먼저 add
빠진 파일을 스테이징한 뒤 amend 하면 같은 커밋에 합쳐집니다.
- amend로 합치기
-m없이git commit --amend를 실행하면 에디터가 열려 메시지를 재확인·수정할 수 있습니다. (1단계처럼-m을 붙이면 에디터를 열지 않고 메시지를 바로 확정합니다.)
# 메시지만 고칠 때 git commit --amend -m "회원가입 폼 검증 추가" # 빠뜨린 파일까지 같은 커밋에 넣을 때 git add forgotten.js git commit --amend # 에디터에서 메시지 확인 후 저장
--amend는 직전 커밋을 새 커밋으로 갈아치웁니다. 그래서 아직 push하지 않은(공유 전) 커밋에만 쓰세요. 이미 push해 남들이 받아 간 커밋을 amend 하면 이력이 어긋나 협업에 충돌이 생깁니다.- 마지막 커밋 1개를 풀기
reset --soft HEAD~1로 커밋만 풀고 변경은 스테이징에 남깁니다. - 스테이징 상태 확인
status에 변경이 'Changes to be committed'로 남아 있는지 봅니다. - 원하는 메시지로 다시 커밋
git reset --soft HEAD~1 # 마지막 커밋만 풀기(변경은 스테이징에 보존) git status # 변경이 '커밋 대기'로 남아 있음 git commit -m "회원가입 기능 구현 (폼·검증·에러 처리)"
reset은 세 가지 모드가 있습니다. --soft는 HEAD만 옮겨 커밋을 풀고 변경은 스테이징에 그대로 둡니다. 기본값인 --mixed는 HEAD와 인덱스(스테이징)를 되돌려 변경이 '아직 add 안 된' 상태로 내려옵니다. --hard는 작업 폴더까지 전부 되돌려 변경 자체를 지웁니다. 최근 3개를 합치려면 HEAD~3처럼 숫자를 늘립니다.--hard는 작업 폴더의 변경까지 지우는 파괴적 명령입니다. 이 시나리오에서는 변경을 살려야 하므로 반드시 --soft를 쓰세요. 그리고 reset으로 이력을 고치는 작업은 push 전 커밋에만 합니다.- 지금 작업을 임시 보관
git stash가 변경을 따로 저장하고 작업 폴더를 마지막 커밋 상태로 깨끗이 만듭니다. - 급한 일 처리
깨끗한 상태에서 버그를 고치고 커밋합니다.
- 치워둔 작업 되살리기
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를 씁니다.git stash list로 stash@{0}, stash@{1} 식으로 확인하고, 특정 항목을 꺼내려면 git stash pop stash@{1}처럼 번호를 지정하세요.- 되돌릴 커밋 ID 찾기
log --oneline으로 문제 커밋의 앞 7자리 해시를 확인합니다. - 그 커밋을 되돌리는 새 커밋 만들기
revert는 변경을 거꾸로 적용하는 새 커밋을 추가합니다(이력은 보존). - 되돌림 커밋을 push
팀과 충돌 없이 변경이 취소됩니다.
git log --oneline git revert a1b2c3d # 해당 커밋을 되돌리는 '새 커밋' 생성 git push
revert는 커밋을 지우지 않고, 그 변경을 정반대로 되돌리는 새 커밋을 하나 더 쌓습니다. 그래서 이력이 그대로 남아 누가 봐도 "이 변경을 의도적으로 되돌렸다"는 흐름이 보입니다. push해 공유된 커밋은 이렇게 revert로 되돌려야 합니다.git reset --hard를 쓰지 마세요. 내 쪽 이력만 지워지고 남들의 이력과 어긋나 충돌이 납니다. 공유된 변경의 취소는 언제나 revert입니다. reset은 push 전 커밋에만.git reset --hard를 잘못 실행해, 멀쩡하던 커밋 몇 개가 사라진 것처럼 보입니다. git log에도 안 보여 식은땀이 납니다. 다행히 이 커밋들은 push 여부와 상관없이 로컬에 흔적이 남아 있습니다.
- 과거 HEAD 위치 목록 보기
reflog는 HEAD가 거쳐 간 지점을HEAD@{0},HEAD@{1}… 식으로 보여 줍니다. - 되돌리고 싶은 지점 찾기
reset 직전, 즉 커밋이 멀쩡하던 시점의 항목을 고릅니다.
- 그 지점으로 복구
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는 로컬 전용이라 다른 컴퓨터에서 복제한 저장소에는 이 기록이 없습니다.- 현재 상태에 백업 라벨 달기
git branch backup-...으로 지금 커밋에 브랜치 이름을 남겨 둡니다. - 안심하고 위험한 정리 작업 진행
꼬여도 백업 브랜치가 원래 지점을 가리키고 있습니다.
- 잘못되면 백업으로 복귀
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로 지워도 됩니다.git reset --hard backup-...은 현재 브랜치의 이후 작업을 전부 버리는 파괴적 명령입니다. 정말 백업 지점으로 되돌릴 의도가 맞는지 확인하고 실행하세요. 그래도 실수했다면 P-1의 reflog로 복구를 시도할 수 있습니다.
Git 2.54.0 기준 · 2026년 6월 13일 작성
📖 되돌리기 매뉴얼 → |
Git 기초 실습 →