반응형
📊 한눈에 보는 차이점
구분ResetRevert
| 히스토리 | 삭제/변경 | 보존 |
| 안전성 | 위험할 수 있음 | 안전함 |
| 협업 | 문제 발생 가능 | 협업 친화적 |
| 되돌리기 방식 | 시간을 되감기 | 새로운 커밋으로 취소 |
🔄 Reset: "시간을 되감는다"
작동 방식
- 커밋 히스토리를 실제로 지우거나 변경
- HEAD 포인터를 이전 커밋으로 이동
- 마치 해당 커밋이 없었던 것처럼 만듦
Reset 옵션들
bash
# 1. --soft: 커밋만 취소, 변경사항은 staged 상태로 유지
git reset --soft HEAD~1
# 2. --mixed (기본값): 커밋 취소, 변경사항은 unstaged 상태로 유지
git reset HEAD~1
git reset --mixed HEAD~1
# 3. --hard: 커밋과 모든 변경사항 완전 삭제
git reset --hard HEAD~1사용 예시
이전: A --- B --- C --- D (HEAD)
실행: git reset --hard B
결과: A --- B (HEAD)
(C, D 커밋이 완전히 사라짐)↩️ Revert: "실행 취소 커밋을 만든다"
작동 방식
- 기존 히스토리는 그대로 보존
- 특정 커밋의 변경사항을 반대로 하는 새로운 커밋 생성
- 안전하게 변경사항만 되돌림
사용 예시
bash
# 특정 커밋을 revert
git revert <commit-hash>
# merge 커밋을 revert (-m 1은 main parent를 의미)
git revert -m 1 <merge-commit-hash>
# 여러 커밋을 한번에 revert
git revert <commit1>..<commit2>사용 예시 (히스토리)
이전: A --- B --- C --- D (HEAD)
실행: git revert C
결과: A --- B --- C --- D --- C' (HEAD)
(C'는 C의 변경사항을 되돌리는 새로운 커밋)🎯 언제 어떤 것을 사용해야 할까?
Reset을 사용하는 경우
✅ 아직 push하지 않은 로컬 커밋을 되돌릴 때 ✅ 혼자 작업하는 브랜치에서 실수를 고칠 때 ✅ 임시 커밋들을 정리할 때
bash
# 예: 마지막 커밋의 메시지만 수정하고 싶을 때
git reset --soft HEAD~1
# 수정 후 다시 커밋
git commit -m "수정된 커밋 메시지"Revert를 사용하는 경우
✅ 이미 push한 커밋을 되돌릴 때 ✅ 다른 사람과 공유하는 브랜치에서 작업할 때 ✅ 히스토리를 보존하면서 안전하게 되돌리고 싶을 때 ✅ 특정 기능만 제거하고 싶을 때
bash
# 예: 프로덕션에 배포된 버그가 있는 커밋을 안전하게 되돌리기
git revert abc1234
git push origin main⚠️ 주의사항
Reset 주의사항
- push한 커밋을 reset하면 다른 개발자들과 충돌 발생
- --hard 옵션은 변경사항을 완전히 삭제 (복구 어려움)
- 협업 시 git push --force 사용 시 매우 위험
Revert 주의사항
- merge 커밋을 revert할 때는 -m 옵션 필요
- 여러 번 revert하면 히스토리가 복잡해질 수 있음
- revert한 커밋을 다시 merge하려면 revert를 다시 revert해야 함
🔧 실무 예시
시나리오 1: 로컬에서 실수한 커받
bash
# 마지막 커밋이 잘못됨 (아직 push 안함)
git reset --hard HEAD~1 # ✅ 괜찮음시나리오 2: 이미 push한 커밋에 버그 발견
bash
# 이미 다른 사람들이 pull받은 상태
git revert abc1234 # ✅ 안전함
git push origin main시나리오 3: merge를 되돌리고 싶음
bash
# merge 커밋을 되돌리기
git revert -m 1 merge-commit-hash # ✅ 안전함💡 기억하기 쉬운 요약
Reset: "없었던 일로 만들기" (위험하지만 깔끔) Revert: "실행 취소 기록 남기기" (안전하지만 히스토리 복잡)
황금 규칙: Push한 커밋은 Revert, 안 한 커밋은 Reset!
반응형