Git의 re- 명령어 정리 (revert, reset, restore, rebase)

 

 

보통 Git을 이용해 협업을 하다보면 "아까로 돌아가고싶다.." 혹은 "이 기록 없애고 싶다.." 하는 순간이 있었을 것이다.

Git에는 이런 상황에 도움을 줄 수 있는 명령어들이 존재한다.

 

비슷해 보이지만 서로 다른 역할을 하는 네 가지 re- 명령어의 차이점을 알아보자.

 

Git revert란?

 

Git revert 는 과거 커밋을 취소하는 새로운 커밋을 만드는 명령어이다.

 

동작 방식은 이미 만들어진 특정 버전(Commit)에서 변경된 내용을 반대로 수행하는데, 예를 들어 A 코드를 추가했던 버전을 되돌리고 싶다면, Git이 자동으로 A 코드를 삭제하는 새로운 버전을 하나 더 만들어준다.

 

기존 Commit을 지우지 않기에 프로젝트의 전체 기록(History)를 건드리지 않고 안전하게 되돌릴 수 있다는 장점이 있고, GitHub에 올린 Commit도 취소 가능하며 "이 Commit을 되돌렸다"는 기록이 명확하게 남기에 다른 사람들과 함께 협업하는 공용 브랜치에서 사용하기에 가장 좋다.

 

하지만, 취소 Commit이 계속 남기 때문에 기록이 조금 길어진다는 단점(?)이 있다.

 

명령어 사용법

 

git revert <커밋 해시> 의 형태로 사용하며 여기서 커밋 해시는 git log 명령어를 입력했을 때 나오는 영문+숫자 조합의 고유 번호이다.

 

abc1234가 오타가 있는 버전이라면 git revert abc1234 명령어를 통해 Git이 알아서 "abc1234 버전을 취소함"이라는 새로운 버전을 하나 더 만들어준다.

 

Git reset이란?

 

Git reset 은 현재 브랜치의 기준을 과거 커밋으로 강제로 이동시키는 명령어로, 쉽게 생각하면 특정 시점으로 시간을 완전히 되돌려, 그 이후의 기록은 없었던 일로 만드는 것이다.

 

동작 방식은 내가 돌아가고 싶은 지점으로 시간을 점프하는 것인데 이 때 세 가지 옵션에 따라 결과가 달라진다.

 

• --soft : 기록(Commit)만 지우고, 내가 작업했던 코드 파일들은 그대로 둔다. (Staging 상태 유지)
  
  
• --mixed (기본 설정) : 기록(Commit)도 지우고 Staging도 취소하지만, 코드 파일은 남겨둔다. 
  
  
• --hard : 기록, 대기 목록, 코드 파일까지 전부 그 당시 상태로 싹 다 되돌린다.

 

잘못 만든 기록을 깔끔하게 지울 수 있고 작업 중인 커밋을 자유롭게 수정할 수 있기에 내 컴퓨터에서만 작업할 때 매우 유용하다. 하지만, 이미 GitHub등에 올린 기록을 지우면 다른 팀원들의 코드와 충돌이 발생할 수 있기에 매우 위험하다.
(프로젝트의 History가 강제로 바뀜)

 

명령어 사용법

 

git reset --soft <커밋 해시> : 커밋만 되돌리고 파일 내용이나 Staging 상태(Commit 대기 상태)는 유지한다.

=> 커밋을 메세지만 다시 쓰고 싶을 때 사용한다. 
(ex. Commit 메세지에 오타가 났거나 Commit을 하나로 합치고 싶을 때 사용)

 

git reset <커밋 해시 > : 기본적으로 --mixed 설정을 따르기 때문에 이 경우 Commit과 Staging 상태를 취소하고 파일 내용만 유지한다.

=> 커밋을 취소하고 다시 수정하고 싶을 때 사용한다.
(ex. Commit에 넣지 말아야 할 파일을 넣었으면 git add를 통해 Commit에 포함할 파일들을 다시 골라낼 때 사용)

 

git reset <커밋 해시> --hard : Commit, Staging, 파일 내용까지 모두 삭제한다.

 

=> 이 커밋 이후는 전부 필요가 없을 때 사용하며 되돌릴 수 없을 수도 있기에 신중하게 사용해야한다.

 

Git restore란?

 

Git restore 는 파일 단위로 변경 사항을 되돌리는 명령어이며 Git reset 명령어 보다 훨씬 안전하고 직관적이며 권장되는 방식이다.

 

동작 방식은 수정 중인 파일이나 Staging(Commit 대기 상태) 상태의 파일을 특정 상태로 복구 하는 것이다.

=> git commit을 한 상태라면 git reset을 우선적으로 해줘야함

 

Git reset 이 프로젝트 전체의 시간을 되돌리는 느낌이라면, restore는 파일 단위로  작동한다.

=> 실수로 파일을 지웠거나 코드를 이상하게 수정했을 때, 마지막으로 저장된 상태로 해당 파일만 되돌려줌

 

우선 Git restore 명령어는 파일 단위의 되돌림이라 굉장히 안전하고 세밀하게 관리하기 좋다.

하지만, Commit History 자체를 조작하지는 못하기에 reset과의 차이점이 있다.

 

Git reset 은 버전 기록(Commit)을 관리하는데 집중하고, Git restore 는 현재 작업 중인 파일을 복구하는 데 집중함

 

 

명령어 사용법

 

git restore <파일명> 을 통해  파일을 마지막 커밋 상태로 되돌릴 수 있다.

 

=> 파일 수정한 것들이 다 필요 없을 때 사용함

 

git restore --staged <파일명> 처럼 --staged 옵션을 사용하면 git add 했던 파일을 취소한다.

 

=> 이 때는 내가 해당 파일에 수정한 코드는 그대로 유지되고 단순히 Staging에서 해당 파일만 빼는 식으로 동작하므로 이 파일을 Commit에 포함 하지 않을 때 사용함

 

git restore --source <커밋 해시> <파일명> 처럼 --source 옵션을 사용하면 해당 해시값에 해당하는 시점을 참고해서 그 시점의 여러 파일 중 <파일명>에 적힌 파일만 꺼내와서 과거 시점의 내용으로 해당 파일이 바뀌게된다.
(나머지 파일은 그대로 유지됨)

 

=> 해시값 대신 HEAD~3(현재로부터 3개 전 커밋) 같은 표현을 써도 동작함

 

Git rebase란?

 

Git rebase 는 커밋들을 다시 정렬해서 히스토리를 깔끔하게 만드는 명령어이다. 

 

https://youtu.be/5jf6_Wnn4QE?si=rQGndDWjJZRnxH_I

위의 영상을 보면 쉽게 이해할 수 있는데 영상에서는 '나를 쟤 위로 올려' 를 기억하고 있으면 절대 까먹지 않는다고 설명을 해주신다.

 

 

동작 방식은 내 작업의 시작점을 다른 최신 시점으로 옮겨서, 마치 처음부터 거기서 시작한 것처럼 만드는 것이다.

 

여러명이 협업하다 보면 Branch가 여러 개 생기게 될텐데 이때 Git rebase 를 사용하면 복잡하게 얽힌 Branch들을 잘라서 메인이 되는 Branch 끝에 일렬로 붙여준다.

 

출처 : https://www.youtube.com/watch?v=5jf6_Wnn4QE

 

 

위 영상을 보면 이런 그림으로 설명이 되어있는데 이걸 보며 굉장히 쉽다.

 

master branch의 commit 3에서 분기된 feature branch가 있는데 feature branch에서 git rebase master 명령어를 사용하면

 

'나를 쟤 위로 올려' 를 기억하라고 했던대로

 

'나(현재 branch인 feature)를 쟤(rebase 명령어에서 지정한 대상인 master) 위로(지정한 master branch의 최신 commit 다음 위치)로 올려' 로 동작하여 프로젝트의 History가 일자로 이쁘게 바뀐다.

 

이렇게 하면 프로젝트 기록이 꼬이지 않고 한 줄로 쭉 이어지기에 커밋을 보기 굉장히 편해진다.

하지만, reset과 마찬가지로 이미 올린 Commit의 뿌리를 바꾸면 동료들이 혼란에 빠질 수 있기에 조심해야하고, 커밋 해시가 바뀌게 된다.

 

=> Git의 커밋 해시는 Parent Commit(바로 직전 부모 커밋)의 해시값에 영향을 받으므로 뿌리가 변경되면 당연히 현재 Commit의 해시도 변경됨