git reset vs git restore
· 업데이트 3회
들어가기
클로드(Claude)에게 수정한 파일들을 되돌리는 방법에 대해서 질문을 했다.
수정한 파일들 되돌리고 싶은데... reset 쓰면 되나요?
응답으로 reset 과 restore 에 대해서 알려주었다.
reset 은 알고 있었지만 restore를 처음 들어보았다.
restore 에 대해 알아보고, reset 과 restore 차이에 대해서 간단하게 정리해보자.
핵심은 "무엇을" 되돌리느냐
git reset → 커밋 히스토리를 움직인다
git restore → 파일 내용을 되돌린다
이게 전부이다.
다음으로 넘어가기 전에 다음 그림 한 장 보고 대략 이해해보자.
git reset: "커밋을 없던 일로"
git reset HEAD~1방금 한 커밋이 마음에 안 들 때. HEAD 포인터 자체를 과거로 옮긴다. 커밋 히스토리가 바뀐다.
세 가지 모드가 있다.
--soft: 커밋만 취소, 변경사항은 staged 상태로 유지(add 되어있는 상태)--mixed(기본): 커밋 취소 + unstage 상태로(다시 add 해야함)--hard: 모든 흔적을 지움 (주의!) -> 팀과 함께 하고 있다면 다른 팀에게 피해를 줄 수 있다.
git restore: "파일을 원래대로"
git restore app.js작업하다 망쳤을 때. Working Directory에 있는 특정 파일만 Staging Area기준의 파일로 복구한다.
Staging Area에 있는 파일도 복구할 수 있다. --staged 옵션을 붙여주면 된다.
그러게 되면 기준점(HEAD:마지막 커밋)의 파일 내용으로 Staging Area에 있는 파일을 복구한다.
git restore --staged app.jsQ) 그럼.. staged된 파일에 --staged 옵션 없이
git restore하면 어떻게 될까?
A) Staging Area에 있는 파일은 그대로이며, Working Directory에 있는 파일만 Staging 기준으로 복구된다.
Q) 아니 그럼.. 내가 수정한 파일들 모두 되돌릴려면 git restore / git restore --staged 둘다 해야함?
A) 네, 대신 git restore -SW 를 사용하면 된다.
왜 이렇게 나뉘었을까?
사실 예전에는 git checkout이 이 모든 걸 담당했다. 파일 복구도, 브랜치 이동도 전부다.
Git 2.23부터 역할이 분리되었다.
checkout→ 브랜치 이동은switch로checkout→ 파일 복구는restore로
명확한 의도를 코드에 담을 수 있게 되었다.
예전에 파일 복구는 다음으로 진행했었다.
- git checkout -- .
- git checkout HEAD -- .
('--' 이 자리에 브랜치이름이 들어가면 해당 브랜치로 이동하는 것!)
실전 치트시트
커밋 취소하고 다시 작성 ->
git reset --soft HEAD~1수정한 파일 되돌리기 ->
git restore <파일>add 취소 ->
git restore --staged <파일>커밋 완전히 삭제 ->
git reset --hard HEAD~1
마무리
reset은 역사를 바꾸는 타임머신이고,restore는 특정 파일만 복구하는 Ctrl+Z이다.