[Git] revert / reset 비교

안녕하세요. J4J입니다.

 

이번 포스팅은 revert와 reset을 비교해보는 시간을 가져보려고 합니다.

 

 

 

revert

 

[ 기본 사용 방법 ]

 

revert의 특징은 다음과 같습니다.

 

• 특정 commit에 의해 반영된 변경사항을 되돌린다.
• revert를 수행한 것도 결국 commit 되기 때문에 로그에서 확인이 가능하다.

 

예를 들어 다음과 같은 commit된 로그들이 있습니다.

 

commit 로그

 

 

그리고 각각의 commit들마다 파일을 한 개씩 생성하여 다음과 같이 파일 구성이 되어있습니다.

 

파일 구성

 

 

여기서 만약 "두 번째 파일"이라는 이름의 commit내용이 잘못되었다고 했을 때 revert를 이용하여 해당 commit만 되돌릴 수 있습니다.

 

사용하는 명령어는 다음과 같습니다.

 

git revert {commit 명} or git revert head~{head와의 거리}

 

 

명령어를 이용하여 revert를 해보겠습니다. (git revert head~2를 입력해도 동일한 결과)

 

git revert

 

 

revert를 했더니 "두 번째 파일" 이라는 commit에 의해 수행되었던 second.txt 파일이 사라진 것을 확인할 수 있게 됩니다.

 

그리고 로그를 다시 확인해보면 다음과 같이 revert가 되었다는 commit도 확인이 가능합니다.

 

revert 로그

 

 

반응형

 

 

[ 바로 commit되지 않게 하는 방법 ]

 

여기서 만약 revert를 수행할 때 revert 한 내역이 바로 commit 되지 않게 하는 방법이 있는데 해당 명령어는 다음과 같습니다.

 

git revert --no-commit {commit 명} or git revert --no-commit head~{head와의 거리}

 

 

파일 구조를 초기로 되돌리고 다음 명령어를 수행하면 commit은 되지 않고 commit 이전의 상태까지만 revert가 된 것을 확인할 수 있습니다.

 

revert --no-commit

 

 

[ 한 번에 여러개를 revert 하는 방법 ]

 

위와 같이 하나씩 revert를 하는 것이 아닌 시간 순서대로 되어 있는 commit들을 한 번에 revert 하는 방법도 있습니다.

 

명령어는 다음과 같습니다.

 

git revert {순서가 빠른 commit 명}..{순서가 늦은 commit 명}
or
git revert head~{head와의 먼 거리}..head~{head와의 가까운 거리}

 

 

파일 구조를 초기로 되돌린 뒤 다음과 같이 여러 개의 commit들을 revert해보겠습니다.

 

multple revert

 

 

여기서 확인하셔야 될 것은 제가 revert를 위해 선택한 {순서가 빠른 commit 명}은 "두 번째 파일"이고 {순서가 늦은 commit 명}은 "네 번째 파일"입니다.

 

하지만 revert가 된 것은 "세 번째 파일", "네 번째 파일"입니다.

 

이렇게 revert가 수행된 이유는 {순서가 빠른 commit 명}에 해당하는 commit은 revert가 되지 않고 그다음에 존재하는 commit들부터 revert 되기 때문입니다.

 

 

 

reset

 

[ 기본 사용 방법 ]

 

reset의 특징은 다음과 같습니다.

 

• 특정 commit의 위치로 되돌림
• reset을 수행한 것은 로그에서 확인이 불가능
• hard reset → working directory부터 local repository까지 되돌림 (작업하기 전 상태)
• mixed reset → staging area부터 local repository까지 되돌림 (add 전 상태)
• soft reset → local repository만 되돌림 (commit 전 상태)

 

 

728x90

 

 

예시는 위에서 진행한 multiple revert의 상태로 해보겠습니다.

 

mutiple revert를 수행했기 때문에 다음과 같이 revert 된 로그가 남겨져 있는 것을 확인할 수 있습니다.

 

multiple revert 이후 로그

 

 

여기서 만약 revert를 수행한 것이 잘못된 행동이어서 revert를 하기 이전의 상태로 되돌리고 싶을 때 reset을 이용할 수 있습니다.

 

reset을 사용하기 위한 명령어는 다음과 같습니다.

 

git reset {soft/mixed/hard} {되돌아갈 commit 명}
or
git reset {soft/mixed/hard} head~{되돌아갈 head와의 거리}

 

 

명령어를 이용하여 hard reset을 수행해보겠습니다. (git reset --hard head~2를 입력해도 동일한 결과)

 

hard reset

 

 

revert 하기 이전의 commit으로 reset이 되어 지워졌던 파일들이 다시 되돌려진 것을 확인할 수 있습니다.

 

또한 로그를 확인해보면 이전에 revert를 수행했던 내용들이 사라진 것도 확인할 수 있습니다.

 

reset 후 로그

 

 

[ reset 사용 시 push ]

 

reset을 한 후 push를 하면 가끔 문제가 발생되는 상황이 존재합니다.

 

왜냐하면 Remote Repository의 현재 위치보다 더 뒤로 reset을 해버리기 때문입니다.

 

예를 들어 바로 위의 사진에서 Remote Repository의 현재 위치는 origin/master에 해당되는 곳입니다.

 

하지만 만약 "세 번째 파일"이라는 commit 위치로 reset을 한 후 push를 하게 되면 Remote Repository는 변경사항을 올바르게 이해하지 못하고 에러를 발생시킵니다.

 

이런 경우 만약 Remote Repsitory에 변경사항을 적용시키고 싶다면 강제 push를 해주면 됩니다.

 

명령어는 다음과 같습니다.

 

git push -f origin master

 

 

개인적인 견해

 

개인적으로 revert와 reset의 가장 큰 차이는 commit을 되돌린 것에 대한 로그 존재 유무라고 생각합니다.

 

만약 혼자서 개발을 한다고 하면 문제 될 것이 없지만 여러 사람들과 같이 협업을 하는 상황 속에서는 로그가 있는 것이 중요한 요소라고 생각합니다. (혼자 하더라도 기록이 있는 것은 중요하다고 생각합니다)

 

그렇기 때문에 로그를 남기고 싶다면 revert, 로그를 남기고 싶지 않다면 reset 사용을 추천드립니다.

 

 

 

 

이상으로 revert와 reset을 간단하게 비교해보는 시간이었습니다.

 

읽어주셔서 감사합니다.