코딩을 하다 보면 누구나 한 번씩 등에 식은땀이 흐르는 순간이 옵니다. "방금 잘 되던 코드를 엉망으로 고쳐버렸다", "필요 없는 파일까지 커밋했다", "커밋 메시지를 'ㅁㄴㅇㄹ'로 보내버렸다"… 그리고 마음속으로 외치죠. "아, 방금 그거 되돌리고 싶다."
좋은 소식이 있습니다. Git을 쓰고 있다면 이 대부분은 되돌릴 수 있습니다. 1·2편에서 '사진을 찍는다(커밋)'고 배웠고, 3편에서 'GitHub에 올린다(push)'고 했죠. 이번 4편은 일종의 '시간 되감기'입니다. 잘못 찍은 사진을 지우고, 방금 컷을 다시 찍고, 필요하면 사진첩을 통째로 과거 시점으로 되돌리는 법까지 배웁니다.
단, 시간 여행에는 규칙이 있어요. 어떤 명령은 되돌린 내용을 영영 지워버립니다. 그래서 이번 글은 "무엇을 쓰느냐"보다 "언제 무엇을 쓰면 안전한가"에 더 무게를 둡니다. 천천히 따라오세요.
되돌리기 전에 — "어디까지 갔나"부터 본다
되돌리기의 핵심은 의외로 단순합니다. 지금 내 실수가 '어느 단계'에 있느냐에 따라 쓰는 명령이 달라요. 2편에서 본 Git의 세 공간을 떠올리면 됩니다.
| 실수가 있는 곳 | 상태 | 되돌리는 명령 |
|---|---|---|
| 작업 디렉토리 아직 git add 안 함 |
파일만 고친 상태 | git restore |
| 스테이징 영역 git add는 했고 커밋 전 |
구도만 잡은 상태 | git restore --staged |
| 저장소 이미 커밋함 |
사진을 찍은 상태 | --amend / reset / revert |
그러니 당황스러운 상황이 오면 먼저 git status로 "내가 지금 어느 단계지?"를 확인하는 습관부터 들이면 됩니다. 그럼 위에서부터 하나씩 볼게요.
1단계 — 아직 커밋 안 했다면: git restore
가장 흔하고, 가장 되돌리기 쉬운 경우입니다. 아직 사진(커밋)을 안 찍었으니 부담 없이 무를 수 있어요.
git add를 취소하고 싶을 때 (스테이징 빼기)
2편에서 잠깐 봤던 명령이죠. git add로 구도에 올린 파일을 다시 내리고 싶을 때 씁니다.
git restore --staged README.md이러면 README.md가 스테이징 영역에서 작업 디렉토리로 다시 내려옵니다. 파일 내용은 그대로 두고, '이번 사진엔 안 담을게'라고 구도에서만 빼는 것이라 안전합니다.
파일 수정 자체를 되돌리고 싶을 때
고치다 보니 영 엉망이 됐고, "그냥 마지막으로 저장(커밋)했던 상태로 되돌리고 싶다" 할 때는 --staged 없이 씁니다.
git restore README.md이건 되돌릴 수 없습니다 — 신중하게 —git restore <파일>(스테이징 옵션 없이)은 그 파일에 저장 안 한 수정 내용을 영구히 지웁니다. Git이 실제로 데이터를 되살릴 수 없게 만드는 몇 안 되는 명령 중 하나예요. "이 수정은 정말 필요 없다"가 확실할 때만 쓰세요. (예전 자료의git checkout <파일>과 같은 동작입니다.)
restore / switch는 왜 생겼나 — 원래는git checkout하나가 '브랜치 이동'과 '파일 되돌리기'를 모두 맡아 너무 헷갈렸습니다. 그래서 Git 2.23(2019년)부터 역할을 둘로 쪼갰어요 — 파일 되돌리기는git restore, 브랜치 이동은git switch. 초보라면 헷갈리는checkout대신 이 둘을 쓰는 걸 권합니다.
2단계 — 방금 커밋했는데 아차: git commit --amend
커밋을 누르자마자 깨닫는 실수가 있죠. 메시지에 오타를 냈거나, 파일 하나를 빼먹고 커밋한 경우입니다. 이럴 땐 새 커밋을 또 만들 필요 없이 방금 그 커밋을 고쳐 치면 됩니다.
# 빠뜨린 파일이 있다면 먼저 add 한 뒤
git add 빠뜨린파일.js
# 마지막 커밋을 다시 작성 (메시지도 수정 가능)
git commit --amend명령을 치면 편집기가 열려 커밋 메시지를 고칠 수 있고, 방금 add한 파일도 그 커밋에 함께 들어갑니다. 마치 방금 찍은 사진이 마음에 안 들어 같은 구도로 다시 찍는 느낌이에요.
이미 push한 커밋은 amend 금지 —--amend는 기존 커밋을 '수정'하는 게 아니라 완전히 새 커밋으로 교체합니다(고유 번호가 바뀝니다). 그래서 아직 내 컴퓨터에만 있는(push 전) 커밋에만 쓰세요. 이미 GitHub에 올린 커밋을 amend하면, 같이 작업하는 동료의 기록과 어긋나 큰 혼란이 생깁니다. (이 원칙은 뒤의 reset에도 똑같이 적용돼요.)
3단계 — 커밋을 통째로 무르기: reset과 revert
"이 커밋 자체를 없던 일로 하고 싶다." 여기엔 성격이 다른 두 갈래 길이 있습니다. 이 둘의 차이를 아는 게 오늘의 핵심이에요.
- git reset — 브랜치를 과거 시점으로 되감습니다. 최근 커밋을 역사에서 밀어내는 방식이라, 깔끔하지만 혼자 작업할 때(아직 push 안 함) 어울립니다.
- git revert — 되돌리는 '새 커밋'을 하나 추가합니다. 원래 커밋은 역사에 그대로 남고, 그 변경을 상쇄하는 커밋을 위에 쌓아요. 역사를 지우지 않으니 이미 push한(공유된) 커밋에 안전합니다.
git reset — 되감기 (세 가지 모드)
reset은 "어디까지 되돌릴까"에 따라 세 모드가 있습니다. 직전 커밋 하나를 무른다고 할 때(HEAD~1은 '직전 커밋'이라는 뜻) 차이는 이렇습니다.
| 모드 | 커밋 | 스테이징(add) | 내 파일 수정 |
|---|---|---|---|
--soft |
무름 | 유지 | 유지 |
--mixed (기본) |
무름 | 무름 | 유지 |
--hard |
무름 | 무름 | 삭제 ⚠️ |
# 직전 커밋만 살짝 무르기 (수정 내용은 그대로 남음 → 다시 커밋 가능)
git reset --soft HEAD~1표를 보면 --soft와 --mixed는 내가 고친 코드는 건드리지 않습니다. 커밋만(또는 커밋과 add까지) 무를 뿐이라, "커밋을 잘못 묶었으니 다시 정리하자" 할 때 안전하게 쓸 수 있어요. 문제는 마지막 --hard입니다.
git reset --hard는 가장 위험한 명령입니다 — 이 옵션은 커밋·스테이징뿐 아니라 아직 커밋하지 않은 내 코드 수정까지 강제로 덮어써 영구 삭제합니다. Git이 데이터를 실제로 지우는 드문 경우예요. 정말 모든 걸 되돌릴 확신이 있을 때만, 그것도git status로 한 번 확인하고 쓰세요.
git revert — 되돌리는 새 커밋 만들기
되돌리고 싶은 커밋의 고유 번호(git log로 확인)를 적어주면, Git이 그 변경을 거꾸로 적용한 새 커밋을 만들어 줍니다.
git revert a1b2c3d원래 커밋은 사진첩에 그대로 남고, 그 위에 "방금 그거 취소함"이라는 도장 사진이 한 장 더 찍히는 셈입니다. 역사를 지우지 않기 때문에, 이미 GitHub에 올렸거나 동료와 함께 쓰는 코드를 되돌릴 땐 거의 항상 이쪽이 정답이에요.
가장 중요한 안전 규칙 하나
오늘 다른 건 다 잊어도 이거 하나는 기억하세요.
이미 push한 커밋은 reset/amend로 되감지 말고, revert로 되돌리세요. 내 컴퓨터에만 있는(push 전) 커밋은reset·--amend로 자유롭게 정리해도 됩니다. 하지만 GitHub에 올라가 남들과 공유된 커밋을 되감은 뒤 강제로 덮어쓰면(force push), 같이 작업하는 사람들의 기록이 어긋나 협업이 꼬입니다. 공유된 역사는 reset이 아니라 revert로.
생명줄 — git reflog (실수해도 되찾는다)
여기까지 읽고 "그러다 reset --hard로 실수하면 어쩌지?" 겁이 났다면, 마지막으로 든든한 보험을 하나 알려드릴게요. git reflog입니다.
Git은 여러분이 commit·reset 같은 작업으로 HEAD(현재 위치)를 움직일 때마다, 그 이동 기록을 몰래 따로 적어 둡니다. 그래서 실수로 커밋을 날린 것 같아도, 그 커밋은 한동안 사라지지 않고 기록에 남아 있어요.
# 그동안의 이동 기록을 본다 (날아간 줄 알았던 커밋의 번호가 보인다)
git reflog
# 그 번호로 되돌아간다
git reset --hard a1b2c3d즉, 커밋까지 한 번이라도 해둔 작업은 웬만해선 진짜로 사라지지 않습니다. (그래서 작업이 어느 정도 되면 일단 커밋부터 해두는 습관이 그렇게 중요한 거예요.) 단, reflog는 커밋된 것을 되살리는 도구라, 애초에 커밋도 add도 안 했던 작업 디렉토리 수정은 못 되살립니다 — 그 부분이 restore <파일>·reset --hard를 조심해야 하는 이유고요.
정리 — 되돌릴 수 있다는 안심
오늘은 명령을 많이 봤지만, 실전에서 기억할 건 결국 "내 실수가 어느 단계에 있나" 하나입니다. 아직 커밋 전이면 restore로 가볍게 무르고, 방금 커밋이 아쉬우면 --amend로 다시 찍고, 커밋을 통째로 물러야 하면 혼자일 땐 reset·공유됐을 땐 revert를 떠올리면 됩니다.
그리고 마음 한구석엔 reflog라는 안전망이 있다는 것. 사실 이 안심이야말로 Git을 쓰는 진짜 이유 중 하나예요. 마음껏 시도하고, 망치면 되돌리면 된다는 자신감 말이죠.
다음 5편에서는 드디어 '평행 우주'에서 안전하게 개발하는 법(브랜치와 병합)을 다룹니다. 원본은 그대로 둔 채 새 갈래를 따서 마음껏 실험하고, 잘되면 합치는 — 협업과 실험의 진짜 무대가 열립니다.
참고 자료
'Hello Dev' 카테고리의 다른 글
| 오픈소스와 팀 협업의 꽃 — Fork·Clone과 Pull Request로 첫 기여하기 (0) | 2026.06.23 |
|---|---|
| 평행 우주에서 안전하게 개발하기 — Git 브랜치·병합(merge)과 충돌(conflict) 해결 (0) | 2026.06.22 |
| 내 코드를 클라우드에 백업하기 — GitHub에 처음 git push 하기 (인스타에 사진 올리듯) (0) | 2026.06.22 |
| 내 코드의 첫 저장점 만들기 — git add와 commit, 사진 찍듯 이해하기 (0) | 2026.06.19 |
| Git이 대체 뭐길래? 10분 만에 이해하는 핵심 개념과 설치 가이드 (0) | 2026.06.17 |