[GitHub] git revert 와 reset의 차이

git revert VS git reset

- 둘 다 Git에서 이전 커밋을 조작하는 데 사용되지만, 그 방식과 목적에 있어서 중요한 차이가 있음

 

1. git revert

• 목적: 이전 커밋을 취소하고, 이전 상태로 돌아가면서 새로운 커밋을 생성 -> 다시 말해, 특정 커밋의 변경사항을 되돌리면서, 새로운 커밋을 만들어 현재 브랜치에 적용
• 사용 시나리오: 이미 공유된 브랜치에서 커밋을 취소하고자 할 때, 특히 이미 리모트 저장소에 푸시된 상태에서 사용

git revert <commit-hash>

 

2. git reset

• 목적: 특정 커밋을 특정 지점까지 하나 이상의 작업트리, 인덱스, 커밋에 대해 이전 상태로 되돌림 -soft, -mixed, -hard 와 같은 옵션을 사용하여 작업트리 및 인덱스까지 리셋 여부를 결정
• 사용 시나리오: 로컬에서 아직 공유되지 않은 변경사항을 되돌리거나, 작업 트리 및 인덱스까지 원하는 지점으로 되돌리고 싶을 때 사용됩니다.

# --soft: 커밋만 되돌림 (작업 트리 및 인덱스는 유지)
git reset --soft <commit-hash>

# --mixed: 커밋 및 인덱스를 되돌림 (작업 트리는 유지)
git reset --mixed <commit-hash>

# --hard: 커밋, 인덱스, 작업 트리를 모두 되돌림 (조심해야 함)
git reset --hard <commit-hash>

 

 

git reset을 사용할 때는 주의가 필요하며, 특히 -hard 옵션을 사용할 경우 작업 트리의 변경사항이 모두 삭제되므로 신중하게 사용

git revert는 이전 커밋을 수정하지 않고 새로운 커밋을 생성하므로 기존 커밋 히스토리를 변경하지 않음

 

git revert 예제

다음과 같은 커밋 히스토리가 있다고 가정

A -- B -- C -- D (현재 브랜치)

커밋 `C` 에서 버그가 발생했다고 가정하고 해당 변경 사항을 되돌리고 싶다면 git revert를 사용

# 커밋 C에서 발생한 변경 사항을 되돌림
git revert C

이 명령어는 새로운 커밋을 생성합니다. 이를 `E` 라고 부르면

이 커밋은 커밋 `C` 에서 발생한 변경 사항을 취소하는 역할을 함

커밋 히스토리는 다음과 같음

A -- B -- C -- D -- E (현재 브랜치)

이 방법은 이미 다른 사람들과 변경 사항을 공유한 경우에 유용

커밋 히스토리를 깔끔하고 선형적으로 유지하면서 특정 커밋을 제거할 수 있음

 

git reset 예제

이제 같은 커밋 히스토리를 고려

A -- B -- C -- D (현재 브랜치)

만약 커밋 `C`와 `D` 를 완전히 히스토리에서 제거하고 싶다면

(git reset**은 주의해서 사용해야 합니다. 모든 변경 사항을 삭제하기 때문)

# 커밋 B로 리셋하고, 커밋 C와 D를 버림
git reset --hard B

이후에 커밋 히스토리는 다음과 같음

A -- B (현재 브랜치)

이 예제에서는 커밋 `C`와 `D`가 히스토리에서 완전히 제거

git reset --hard는 작업 디렉토리의 모든 변경 사항을 삭제하므로 주의가 필요

 

git revert 와 git reset 중 어떤 것을 선택할지는 변경 사항이 이미 공유되었는지, 그리고 깔끔하고 선형적인 히스토리를 유지하고 싶은지에 따라 다르다~!!!