Git reset이란 무엇인가?
git reset은 Git 저장소의 상태를 특정 커밋으로 되돌리는 데 사용되는 강력하고 다재다능한 명령어입니다. 이 명령은 주로 브랜치의 포인터(HEAD)를 과거의 특정 커밋으로 이동시키는 역할을 합니다. 하지만 reset은 어떤 옵션을 사용하느냐에 따라 인덱스(Staging Area)와 워킹 디렉터리(Working Directory)에 미치는 영향이 크게 달라지기 때문에, 각 옵션의 차이를 명확히 이해하고 사용해야 합니다.
Git의 세 가지 상태 영역을 먼저 이해해야 합니다:
- 워킹 디렉터리 (Working Directory): 현재 작업 중인 실제 파일들.
- 인덱스 (Index / Staging Area): 다음 커밋에 포함될 변경 사항들의 목록.
- HEAD: 현재 브랜치가 가리키는 마지막 커밋.
git reset의 세 가지 옵션
git reset의 핵심은 이 세 가지 영역 중 어디까지를 되돌릴 것인지를 결정하는 것입니다.
1. git reset --soft <commit>
--soft 옵션은 가장 소극적인 리셋입니다. 이 명령은 오직 HEAD 포인터만 지정된 커밋으로 이동시킵니다. 인덱스와 워킹 디렉터리는 전혀 건드리지 않습니다.
- 동작:
HEAD를<commit>으로 이동시킨다. - 결과:
HEAD가 가리키는 커밋이 변경됩니다.- 인덱스(Staging Area)는 그대로 유지됩니다. 즉,
reset이전의HEAD와<commit>사이의 모든 변경 사항이 스테이징된 상태로 남아있습니다. - 워킹 디렉터리의 파일들은 전혀 변경되지 않습니다.
- 주요 사용 사례: 여러 개의 커밋을 하나로 합치고 싶을 때 유용합니다. 예를 들어, 최근 3개의 커밋을 취소하고 하나의 커밋으로 다시 만들고 싶을 때
git reset --soft HEAD~3을 실행하면, 지난 3개 커밋의 모든 변경 사항이 스테이징된 상태로 준비됩니다.
명령어 예시:
# 마지막 커밋을 취소하고, 해당 변경 사항은 스테이징된 상태로 둔다.
git reset --soft HEAD~
2. git reset --mixed <commit> (기본 옵션)
--mixed는 git reset의 기본 옵션입니다. reset 명령을 옵션 없이 실행하면 --mixed로 동작합니다. 이 옵션은 HEAD와 인덱스를 지정된 커밋의 상태로 되돌립니다.
- 동작:
HEAD와 인덱스를<commit>의 상태로 되돌린다. - 결과:
HEAD가 가리키는 커밋이 변경됩니다.- 인덱스가
<commit>시점의 상태로 초기화됩니다. 즉, 스테이징되었던 모든 변경 사항이 취소되고 워킹 디렉터리로 내려옵니다. - 워킹 디렉터리의 파일들은 변경되지 않습니다.
- 주요 사용 사례: 커밋은 취소하고 싶지만, 파일의 변경 내용은 보존하고 싶을 때 사용합니다. 스테이징된 내용을 수정하거나 일부만 다시 스테이징하고 싶을 때 유용합니다.
명령어 예시:
# 마지막 커밋을 취소하고, 해당 변경 사항은 워킹 디렉터리에만 남겨둔다 (스테이징 해제).
git reset --mixed HEAD~ # `git reset HEAD~`와 동일
3. git reset --hard <commit>
--hard는 가장 강력하고 파괴적인 옵션입니다. 이 명령은 HEAD, 인덱스, 그리고 워킹 디렉터리까지 모두 지정된 커밋의 상태로 되돌립니다.
- 동작:
HEAD, 인덱스, 워킹 디렉터리를 모두<commit>의 상태로 되돌린다. - 결과:
HEAD가 가리키는 커밋이 변경됩니다.- 인덱스가
<commit>시점의 상태로 초기화됩니다. - 워킹 디렉터리의 모든 변경 사항이 영구적으로 삭제됩니다.
<commit>이후의 모든 작업 내용이 사라지므로 사용에 극도의 주의가 필요합니다.
- 주요 사용 사례: 최근의 모든 변경 사항(커밋, 스테이징, 워킹 디렉터리 작업 내용)을 완전히 버리고 특정 시점으로 깨끗하게 돌아가고 싶을 때 사용합니다.
명령어 예시:
# 마지막 커밋과 관련된 모든 변경 사항(스테이징, 워킹 디렉터리 내용 포함)을 완전히 삭제한다.
git reset --hard HEAD~
요약
| 옵션 | HEAD (브랜치 포인터) |
인덱스 (Staging Area) | 워킹 디렉터리 (파일) | 주요 용도 |
|---|---|---|---|---|
--soft |
이동 (O) | 변경 없음 (X) | 변경 없음 (X) | 커밋 합치기 (모든 변경 사항을 스테이징) |
--mixed |
이동 (O) | 리셋 (O) | 변경 없음 (X) | 커밋 취소 및 스테이징 수정 (변경 사항 보존) |
--hard |
이동 (O) | 리셋 (O) | 리셋 (O) | 모든 변경 사항 완전 폐기 |
주의사항
git reset은 로컬 저장소의 커밋 히스토리를 변경하는 작업입니다. 이미 원격 저장소에 푸시(push)한 커밋을reset으로 되돌린 후 다시 푸시하려면--force옵션이 필요합니다. 이는 팀원들의 히스토리와 충돌을 일으킬 수 있으므로, 공유된 브랜치에서는git reset대신git revert를 사용하는 것이 더 안전합니다.git reset --hard는 되돌릴 수 없는 작업이므로, 실행하기 전에git status나git log로 현재 상태를 다시 한번 확인하는 것이 좋습니다.
전문 보완 체크
Git 커밋 되돌리기: git reset의 세 가지 옵션 (soft, mixed, hard) 완벽 가이드에서 중요한 기준은 독자가 한 번 따라 해서 성공했는지가 아닙니다. 이 주제는 재현 가능한 디버깅 절차로 다루는 편이 안전합니다. 결론을 내리기 전에 실행 환경, 정확한 오류 경계, 최소 재현 예제, 되돌릴 수 있는 경로를 확인해야 합니다. 또한 나중에 같은 문제가 반복될 수 있으므로, 관찰한 사실과 사용한 가정, 결론이 바뀔 조건을 짧은 결정 기록으로 남기는 것이 좋습니다.
신뢰도를 높이는 증거
작업을 바꾸기 전에는 객관적인 증거를 먼저 확인해야 합니다. 쓸 만한 증거에는 전체 명령 출력, 버전 번호, 변경된 파일, 기대 동작과 실제 동작가 포함됩니다. 증거가 서로 맞지 않으면 억지로 하나의 이야기로 합치지 말고 충돌 자체를 남겨야 합니다. 빠른 해결이 한 번 성공했더라도 같은 입력, 계정, 의존성, 기기 상태에서 다시 확인하지 않았다면 아직 확정된 해결책이라고 보기 어렵습니다.
검토 표
| 검토 항목 | 확인할 내용 | 중요한 이유 |
|---|---|---|
| 범위 | 이 글이 다루는 정확한 사례 | 조언을 과도하게 적용하지 않게 합니다 |
| 기준 상태 | 변경 전 상태 | 되돌리기와 비교를 가능하게 합니다 |
| 변경 | 실제로 수행한 가장 작은 조치 | 숨은 부작용을 줄입니다 |
| 결과 | 변경 뒤 관찰한 출력 또는 반응 | 기대와 증거를 구분합니다 |
| 재확인 | 결론을 다시 볼 시점 | 글의 정확도를 유지합니다 |
예외 상황과 실패 모드
주요 위험은 증상만 고치고 원인을 남기는 상황, 서로 무관한 변경을 같은 테스트에 섞는 상황입니다. 생산 데이터, 개인정보, 돈, 건강, 법적 권리, 보안 복구가 관련되어 있다면 넓은 해결책을 바로 적용하기보다 먼저 증거를 모으는 보수적인 접근이 낫습니다. 같은 제목의 문제라도 환경이 다르면 원인이 달라질 수 있으므로, 독자는 명령이나 결정을 복사하기 전에 자신의 조건이 글의 가정과 맞는지 비교해야 합니다.
유지보수 기준
이 안내는 의존성, 운영체제, 빌드 도구가 바뀐 뒤 다시 확인해야 합니다. 좋은 업데이트는 글 전체를 다시 쓰는 것이 아니라 예시, 링크, 명령, 화면, 판단 기준이 현재 동작과 여전히 맞는지 확인하는 일입니다. 기존 결론이 유효하면 확인 날짜를 남기고, 바뀌었다면 무엇이 바뀌었고 왜 이전 조언만으로 부족한지 설명해야 합니다.
함께 보면 좋은 글
같은 주제 흐름에서 이어서 읽기 좋은 글입니다.
Leave a comment