HOWTO · Git
Git에서 파일을 이전 커밋으로 되돌리기
git restore 또는 git checkout을 사용해 이전 Git 커밋에서 추적 중인 파일을 복원하고, 결과를 확인한 뒤, 스테이징하고 커밋할지 결정하는 방법을 알아봅니다.
이 페이지의 내용
이전 커밋에 기록된 버전으로 추적 중인 파일 하나를 복원하려면, 원하는 버전이 있는 커밋을 찾은 다음 git restore --source <commit> -- <file-path>를 실행합니다. 이 명령은 커밋 기록을 바꾸지 않고 작업 트리의 파일을 갱신하며, 기본적으로 복원한 버전을 스테이징하지 않습니다. 복원하면 작업 트리의 파일 내용이 교체되므로, 먼저 보존할 가치가 있는 로컬 수정 사항을 검토하거나 저장하세요. 복원한 버전을 새 커밋에 기록하려면 나중에 스테이징하고 커밋하면 됩니다.
원하는 버전이 들어 있는 커밋 찾기
파일을 변경한 커밋을 확인하고 원하는 버전이 포함된 커밋을 찾으려면 git log --oneline -- <file-path>를 사용합니다. 예를 들어 저장소 루트에 있는 README.md의 기록을 보려면 git log --oneline -- README.md를 실행합니다. --는 명령 옵션의 끝을 표시하므로, 경로가 옵션으로 해석될 수 있을 때 유용합니다. git log에서 경로는 현재 디렉터리를 기준으로 지정할 수 있습니다. Git의 :(top) 경로 문법을 사용하면 :(top)README.md처럼 저장소 루트 기준 경로를 지정할 수도 있습니다.
커밋 요약을 읽고 필요하면 git show <commit>:<file-path>로 후보 커밋에 들어 있는 파일을 확인합니다. 이 형식에서 콜론 뒤의 경로는 현재 디렉터리와 관계없이 항상 저장소 루트를 기준으로 합니다. 예를 들어 docs 하위 디렉터리에서 git log --oneline -- README.md를 실행해 docs/README.md의 변경 사항을 찾았다면, 해당 버전을 확인할 때는 git show <commit>:docs/README.md를 사용합니다. 저장소 루트의 README.md라면 루트나 하위 디렉터리 어디서든 git show <commit>:README.md를 사용하면 됩니다. 로그에 표시된 커밋 식별자는 축약형이나 전체 형식으로 복원 명령에 사용할 수 있습니다. 이후 커밋에서 같은 파일을 변경했더라도 원하는 버전이 이전 커밋에 있을 수 있으므로, 단순히 가장 최근 커밋을 고르지 말고 되돌려 가져오려는 파일 내용을 기준으로 선택하세요.
이전 커밋에서 파일 복원하기
먼저 대상 파일에 보존할 가치가 있는 수정 사항이 있는지 확인하고 필요하면 저장하세요. 그런 다음 git restore --source <commit> -- <file-path>로 선택한 버전을 복원합니다. 제공된 예에서는 git restore --source 9cbe84d -- README.md를 실행합니다. 커밋과 경로는 저장소의 값으로 바꾸세요. 이 명령은 해당 커밋에 기록된 파일 버전을 작업 트리에 복사합니다. 커밋을 만들거나 현재 브랜치를 이동하지 않으며, 복원한 내용은 기본적으로 스테이징되지 않습니다.
아래 명령 예시는 Git 작업을 보여 주며, 실행 결과를 제시하거나 주장하지 않습니다. 실제 효과는 저장소의 커밋 기록, 현재 인덱스와 작업 트리 상태에 따라 달라집니다. 복원한 뒤 git diff -- <file-path>로 작업 트리의 변경 사항을 확인하세요. 해당 경로에 스테이징된 변경 사항도 있다면 다음 커밋에 무엇이 포함될지 알 수 있도록 git diff --cached -- <file-path>로 스테이징된 버전도 확인하세요.
git restore와 git checkout 중 선택하기
선택한 커밋에서 파일을 가져올 때 git restore --source <commit> -- <file-path>를 사용하면 출처 커밋을 명시할 수 있으며, 기본적으로 결과를 스테이징하지 않고 작업 트리만 갱신합니다. 경로 형식을 사용하는 대안은 git checkout <commit> -- <file-path>입니다. 이 형식은 작업 트리의 파일과 인덱스를 모두 갱신하므로 복원한 버전이 즉시 스테이징됩니다. 커밋을 준비할 때 이 차이가 중요합니다. git checkout을 사용했다면 스테이징된 변경 사항을 확인하고, git restore를 사용했다면 의도한 경우에만 파일을 직접 스테이징하세요.
두 명령 모두 대상 파일의 현재 작업 트리 내용을 교체합니다. 특히 다른 곳에 커밋하지 않은 로컬 수정 사항이 있다면 두 명령 중 하나를 실행하기 전에 검토하거나 저장하세요. 파일을 복원하는 것만으로는 커밋이 만들어지지 않습니다. 복원은 작업을 이어 갈 파일 상태를 바꾸며, 나중에 직접 커밋하기 전까지 브랜치 기록은 그대로 유지됩니다.
복원한 파일 스테이징 및 커밋하기
git restore를 사용한 뒤 변경 사항을 검토하고, 커밋에 포함하려면 git add -- <file-path>로 파일을 스테이징합니다. 그런 다음 git diff --cached -- <file-path>로 스테이징된 버전을 확인하고, 파일을 복원한 이유를 설명하는 메시지로 커밋을 만드세요. 아직 복원 내용을 기록하고 싶지 않다면 작업 트리 변경 사항으로 둡니다.
경로 형식의 git checkout <commit> -- <file-path>를 실행하면 복원한 버전이 이미 인덱스에 들어 있습니다. 커밋하기 전에 git diff --cached -- <file-path>로 확인하세요. 다음 단계에 따라 파일을 더 수정하거나, 그 수정 사항을 스테이징하거나, 작업 트리 내용은 유지하면서 해당 경로를 스테이징 해제할 수 있습니다. 파일 하나를 복원하는 것과 이를 커밋할지는 별개의 선택이며, 복원했다고 변경 사항이 자동으로 게시되거나 공유되지는 않습니다.
파일 작업에서 git revert와 git reset 이해하기
git revert와 파일 복원은 서로 다른 문제를 해결합니다. git revert <commit>은 이전 커밋에서 도입된 변경 사항을 되돌리는 새 커밋을 만듭니다. 기존 기록을 보존하면서 커밋을 취소할 때 사용하는 명령입니다. 이전 커밋에서 파일 하나를 복사해 오는 명령은 아닙니다. 파일 버전 하나를 가져오려면 위의 출처 커밋 지정 복원 절차를 사용한 다음, 그 결과를 커밋할지 결정하세요.
경로 형식의 git reset HEAD -- <file-path>는 해당 경로의 스테이징을 해제합니다. 작업 트리 파일 내용은 그대로 두고 인덱스를 HEAD와 일치시킵니다. 선택한 커밋의 파일 내용을 복원하지는 않습니다. 작업 트리의 수정을 버리고 파일을 현재 HEAD 버전으로 되돌리려면 기본적으로 HEAD에서 복원하는 git restore -- <file-path>를 사용합니다. 이 명령도 작업 트리 내용을 교체하므로 먼저 수정 사항을 검토하거나 저장하세요. 이전 경로 형식인 git checkout -- <file-path>도 비슷하게 작업 트리의 수정을 버리지만, 이전 커밋을 선택하는 기능은 없습니다. 특정 커밋의 버전이 필요하면 명시적인 --source <commit> 형식을 사용하세요.
자세한 내용은 Git restore 문서, Git checkout 문서, Pro Git의 변경 사항 되돌리기 장을 참고하세요.