git 되돌리기, AI 가 코드를 망쳤을 때 restore 와 revert 차이
AI 에게 코드 정리를 맡겼다가 엔진 연결이 끊겨 하루를 날렸다는 하소연을 게임 개발 커뮤니티에서 본 적이 있다. 이럴 때 제일 먼저 드는 생각은 어제 상태로 돌아가고 싶다는 거다. git 을 쓰고 있다면 돌아갈 길은 있다. 근데 명령이 restore, revert, reset 셋이나 되고 이름도 비슷해서 뭘 쳐야 할지 막막하다.
답은 커밋을 했느냐로 갈린다. 아직 커밋하지 않은 파일 변경을 버리려면 git restore, 이미 커밋한 걸 기록을 남긴 채 취소하려면 git revert, 브랜치를 예전 커밋으로 되감으려면 git reset 이다. 셋 중 restore 와 reset --hard 는 커밋 안 한 작업을 지울 수 있어서 조심해야 한다. 아래는 2026년 10월 17일에 연 git 공식 문서와 Pro Git 책, 그리고 이 PC 의 Git 2.56.0 으로 직접 돌려 본 결과 기준이다.
git 되돌리기 전에 commit 부터
되돌리는 명령보다 먼저 알아 둘 게 있다. git 이 확실하게 돌려주는 건 커밋으로 남겨 둔 상태다. Pro Git 의 되돌리기 장은 커밋한 건 거의 언제나 되살릴 수 있지만, 커밋한 적 없는 변경은 잃으면 다시 보기 어렵다고 적어 둔다.
그래서 AI 도구에 큰 수정을 맡기기 전에 지금 상태를 커밋 하나로 남겨 두는 게 제일 싸게 먹히는 보험이다. 그러면 결과가 마음에 안 들 때 그 커밋을 기준으로 아래 명령을 고르면 된다. 맡기기 직전 상태를 커밋이나 stash 로 남기지 않았고 add 해 둔 것도 없다면? 그 상태를 git 만으로 되살리기는 어렵다. 편집기의 실행 취소나 파일 기록 같은 다른 길을 찾아야 한다.
커밋 전 변경을 버리는 git restore
AI 가 파일을 고쳤는데 아직 커밋은 안 했다면 git restore 를 쓴다. git-restore 문서를 보면 git restore 파일 은 그 파일을 스테이징 영역, 그러니까 git add 해 둔 내용으로 되돌린다. add 한 적이 없으면 마지막 커밋 내용으로 돌아간다고 보면 된다. 지금 폴더와 그 아래 파일을 한꺼번에 되돌리려면 git restore . 처럼 경로 자리에 점을 넣는다.
여기서 놓치면 안 되는 게 하나. Pro Git 은 git restore 파일을 위험한 명령이라고 분명히 적는다. 기본 restore 는 add 하지 않은 변경을 그대로 버린다. AI 가 고친 것 중 일부는 살리고 싶다면 restore 하기 전에 바뀐 줄부터 보자. 추적 중인 파일에서 add 안 한 변경은 git diff, add 한 변경은 git diff --cached 로 보인다(git-diff 문서). 살릴 게 있으면 따로 커밋하거나 stash 로 치워 두는 쪽이 안전하다.
커밋 전이라도 git status 를 먼저 봐야 하는 이유가 있다. 이번에 같은 저장소에서 game.js 를 고쳐 git add 까지 하고 새 파일 new.js 도 하나 만든 다음 git restore . 를 돌려 봤다. 파일은 그대로였다. 기본 restore 는 작업 폴더를 add 해 둔 내용에 맞추니까, add 까지 된 변경은 안 사라진다. 이럴 땐 문서에 나온 git restore --source=HEAD --staged --worktree -- 파일 처럼 마지막 커밋 기준으로 add 한 것과 파일을 함께 되돌리면 된다. 돌려 보니 game.js 가 hp 100 으로 돌아왔다. 근데 new.js 는 끝까지 남아 있었다. git 이 추적한 적 없는 새 파일은 restore 로 안 지워지니, AI 가 만든 새 파일은 status 에서 보고 직접 정리해야 한다.
비슷하게 생긴 옵션도 두 개. git restore --staged 파일 은 git add 만 취소하고 파일 내용은 건드리지 않는다. 그리고 --source 를 붙이면 예전 커밋에 있던 파일 하나만 꺼내 올 수 있다. 문서 예시로는 git restore --source master~2 Makefile 처럼 쓴다.
예전 글이나 강좌에서 git checkout -- 파일 을 봤다면 같은 일을 하는 옛 방식이다. Pro Git 에 따르면 restore 는 Git 2.23.0 에서 들어왔다. 버전이 그보다 낮으면 restore 명령이 없으니 git --version 부터 보자.
이미 커밋한 걸 취소하는 git revert
AI 가 고친 걸 커밋까지 해 버렸고, 그 커밋을 취소하고 싶다면 git revert 를 쓴다. git-revert 문서의 설명대로 revert 는 커밋을 지우지 않는다. 그 커밋이 바꾼 내용을 거꾸로 되돌리는 커밋을 새로 하나 만든다. 그래서 잘못한 커밋도, 그걸 취소한 커밋도 기록에 다 남는다.
임시 폴더에 새 저장소를 만들어 직접 돌려 봤다. game.js 에 hp 100 을 넣어 커밋한 다음, 9999 로 바꾸고 restore 로 버려 봤고, 다시 9999 로 바꿔 커밋한 걸 revert 로 취소해 봤다.
중간에 9999 로 다시 바꿔 커밋한 단계는 그림에서 뺐다. restore 뒤엔 파일이 바로 100 으로 돌아왔다. revert 뒤엔 Revert "hp buff" 라는 커밋이 하나 늘었고, 9999 로 바꾼 커밋도 log 에 그대로 남아 있다. 파일 내용은 100 으로 돌아왔고. 출력의 짧은 해시는 저장소마다 다르게 나온다.
revert 에는 조건이 있다. 작업 폴더가 깨끗해야 한다. 커밋 안 한 변경이 남아 있으면? 먼저 커밋하거나 치워야 한다. --no-edit 을 붙이면 커밋 메시지 편집기를 열지 않고 기본 메시지로 커밋한다. 문서는 왜 되돌렸는지 메시지에 적어 두라고 권하긴 한다. 병합 커밋을 되돌릴 땐 어느 쪽을 기준으로 할지 -m 으로 정해야 하고, 병합을 revert 하면 나중에 같은 내용을 다시 병합할 때 꼬일 수 있다고 문서가 경고한다. 처음이라면 병합 커밋 revert 는 문서를 끝까지 읽고 하는 게 낫다.
여럿이 같이 쓰는 브랜치라면 보통 revert 를 먼저 고른다. 기존 커밋 기록을 다시 쓰지 않으니까. revert 도 충돌로 멈출 수 있는데, 그땐 git revert --abort 로 시작 전 상태로 돌아갈 수 있다.
git reset 은 되감기, --hard 는 조심
git reset 은 지금 브랜치가 가리키는 커밋을 예전 커밋으로 옮긴다. 그 뒤의 커밋들은 log 에서 빠지고. git-reset 문서에는 --merge 나 --keep 같은 모드도 있는데, 커밋을 되감을 때 흔히 비교하는 건 세 가지다. --soft 는 커밋만 되감고 add 해 둔 내용과 파일은 그대로 둔다. 아무것도 안 붙이면 --mixed 라서 커밋과 add 를 되감고 파일 내용은 남긴다. --hard 는 파일까지 그 커밋 상태로 덮어쓴다.
문제는 --hard. 커밋 안 한 변경이 사라지고, git 이 추적하지 않던 파일까지 덮어쓸 수 있다. 문서의 예시도 이미 다른 사람에게 넘긴 커밋에는 하지 말라고 적어 둔다. reset 예제는 이번에 돌려 보지 않았다. 처음 쓰는 거라면 reset 은 아직 원격에 올리지 않은 내 커밋에만, 그것도 --hard 말고 --mixed 부터 써 보는 게 마음 편하다. 파일 내용은 남으니까 다시 골라 담을 수 있다.
restore revert reset 중 뭘 쓸까
AI 도구에 맡기기 전에 커밋부터 해 두고, 결과가 이상하면 순서대로 물어보면 된다. 커밋했나? 안 했으면 git status 로 add 여부와 새 파일부터 보고 restore 로 되돌린다. 했으면 그 커밋을 다른 사람과 같이 쓰나? 같이 쓰면 revert 로 취소 커밋을 만든다. 아직 내 PC 에만 있고 기록에서 아예 빼고 싶으면 reset 을 쓰되, 파일까지 날리는 --hard 는 마지막에 고른다. 이 순서만 기억해 둬도 실수했을 때 어떤 명령부터 볼지 덜 헷갈린다. 줄바꿈 일괄 변환으로 그림 파일이 망가졌던 얘기는 PNG 줄바꿈 사고 글에 적었다.
다음엔 윈도우에서 Codex 의 샌드박스와 승인 모드 설정을 어떻게 읽는지 적으려고 한다.