숏컷 코드

# 작업 트리 변경만 버리기
git restore app.js

# 스테이징만 해제하고 파일 수정은 유지
git restore --staged app.js

# 특정 커밋의 파일 내용으로 되돌리기
git restore --source=HEAD~1 -- app.js

# 일부 hunk만 골라서 되돌리기
git restore --patch app.js

되돌리는 위치

git restore는 커밋 히스토리를 옮기는 명령이 아니라 파일 내용을 어느 위치에서 어느 위치로 복사할지 정하는 명령입니다. 기본 대상은 작업 트리입니다. git restore app.js는 인덱스에 있는 app.js 내용으로 작업 트리 파일을 되돌립니다. 아직 스테이징하지 않은 수정이 있었다면 그 수정은 사라집니다.

--staged를 붙이면 대상이 인덱스가 됩니다. 이때 기본 원본은 HEAD이므로 git restore --staged app.js는 스테이징 영역의 app.js를 마지막 커밋 상태로 되돌립니다. 작업 트리의 실제 파일 내용은 그대로 남기기 때문에 git add를 취소하는 용도로 쓸 수 있습니다.

git status
git restore --staged app.js
git status

# Changes to be committed 에서 빠지고
# Changes not staged for commit 으로 내려온다

reset, checkout과의 경계

restore는 파일 단위 복구에 초점을 둡니다. 브랜치 포인터를 옮기거나 커밋을 없애야 한다면 reset을 검토해야 하고, 공개된 커밋의 효과를 취소해야 한다면 revert가 맞습니다. 예전에는 checkout -- <file>을 많이 썼지만, 현재는 브랜치 전환은 switch, 파일 복구는 restore로 나누어 읽는 편이 명확합니다.

# 파일만 되돌림
git restore src/config.js

# 브랜치 포인터와 인덱스 상태까지 바꿈
git reset --mixed HEAD~1

# 공개 커밋을 취소하는 새 커밋을 만듦
git revert a1b2c3d

git restore --source=<commit> -- <file>은 특정 커밋에서 파일 하나만 가져오는 흐름입니다. 브랜치 전체를 과거로 돌리지 않기 때문에 설정 파일, 문서, 테스트 fixture처럼 한 파일만 과거 상태로 비교하거나 되살릴 때 유용합니다.

언제 쓸까

작업 중 잘못 수정한 파일을 버릴 때는 git diff로 먼저 내용을 확인한 뒤 git restore <file>을 실행합니다. 이 명령은 되돌린 수정 내용을 별도로 보관하지 않으므로, 실험 코드라도 다시 필요할 수 있다면 git stash push -p나 임시 커밋을 먼저 고려하는 편이 안전합니다.

git diff app.js
git restore app.js

커밋에 포함하지 않기로 한 파일을 스테이징에서만 빼려면 --staged가 맞습니다. 수정 내용은 파일에 그대로 남아 있으므로 나중에 다른 커밋에 넣거나 추가로 정리할 수 있습니다.

git add app.js debug-notes.md
git restore --staged debug-notes.md
git commit -m "Update app behavior"

여러 파일 중 일부 hunk만 되돌려야 할 때는 --patch가 적합합니다. 한 파일 안에서 유지할 변경과 버릴 변경이 섞여 있을 때 전체 파일을 되돌리는 실수를 줄일 수 있습니다.

주의할 점

restore의 기본 원본은 옵션에 따라 달라집니다. --staged가 없으면 인덱스에서 작업 트리로 복원하고, --staged가 있으면 HEAD에서 인덱스로 복원합니다. 이 차이 때문에 이미 스테이징된 파일에 git restore <file>을 실행하면 작업 트리가 스테이징된 내용과 같아질 뿐, 스테이징 자체가 해제되지는 않습니다.

git add app.js
git restore app.js

# app.js는 여전히 staged 상태일 수 있다
# 스테이징 해제가 목적이면 아래처럼 실행한다
git restore --staged app.js