↩️
reset vs revert, 뭘 언제 쓰나
히스토리를 고치는 법 vs 되돌리는 커밋을 추가하는 법
둘 다 '되돌리기'지만 방식이 완전히 다르다.
reset
브랜치 포인터를 지정한 커밋으로 이동시킨다. 그 이후의 커밋은 히스토리에서 사라진다(객체는 reflog에 남아있긴 함).
--soft: HEAD만 이동. 변경은 staged 상태로 유지--mixed(기본): HEAD 이동 + 인덱스 리셋. 변경은 working tree에 유지--hard: HEAD 이동 + 인덱스 + working tree 전부 리셋. 복구 어려움
revert
지정한 커밋의 반대 변경을 담은 새 커밋을 만든다. 히스토리는 그대로 남고, 끝에 '되돌리기 커밋'이 하나 붙는다.
선택 기준
아직 push 안 했나? reset이 깔끔하다.
이미 push했나? revert를 써야 한다. reset하고 force push하면 다른 사람의 히스토리가 깨진다.
실수 복구
git reset --hard로 뭘 날렸어도 당황하지 말자. git reflog에 최근 HEAD 이동 기록이 남아 있다. 원하는 해시로 다시 reset하면 된다. 기본 30일 보존.
동작 흐름
1
`git reset --soft HEAD~1` → 마지막 커밋 취소, 변경은 staged 유지
2
`git reset --hard <hash>` → 지정 커밋으로 완전 초기화 (위험)
3
`git revert <hash>` → 해당 커밋을 취소하는 새 커밋 생성
4
`git reflog` → HEAD 이동 기록 확인, 실수 복구에 사용
장점
- ✓ reset: 히스토리가 깔끔하게 사라짐
- ✓ revert: 안전, 협업 히스토리를 깨지 않음
단점
- ✗ reset: 공유 브랜치에 쓰면 위험
- ✗ revert: 히스토리에 되돌림 커밋이 남음
사용 사례
reset: 아직 push 전 로컬 커밋 정리
revert: 이미 배포된 문제 커밋 되돌리기
reflog: --hard로 날린 작업 복구