[Today I Learned - 7] Git의 파일 버전관리 메커니즘과 Reset 명령어

1. 버전관리 메커니즘

---

Reset 명령어를 정확하게 이해하기 위해서는 깃이 파일의 버전을 어떻게 관리하는지 이해가 필요하다. 깃은 관리 파일을 Working Directory, Index, HEAD 3가지 영역(?)으로 관리한다.

• Working Directory = 개발자의 작업공간(워크스페이스)
• INDEX(Staging Area) = 체크아웃 이후 파일을 변경하여 커밋의 대상이 파일이 모이는 공간
• HEAD = 현재 브랜치를 가리키는 포인터이며, 브랜치는 브랜치에 담긴 커밋 중 가장 마지막 커밋을 가리킨다

 

쉽게 말하자면 개발자가 코드를 변경하는 곳이 Working Directory, 코드를 변경하여 커밋의 대상이 되는 파일이 모이는 Index, Index에 있는 파일을 커밋하면 저장되는 곳이 HEAD 이다.

 

 

2. Reset

---

reset 명령어는 soft, mixed, hard 옵션에 따라 각 영역을 다르게 조작한다. 

 

 

soft 옵션

브랜치가 가리키는 커밋의 버전을 이전으로 변경한다(HEAD는 여전히 동일한 브랜치를 가리킴)

 

아래의 3개의 커밋 이력(v1, v2, c3)이 있었을 때 reset --soft 명령어를 실행하면 어떻게 동작하는지 파악해보자. 첫번째 이미지를 보면 초기에는 HEAD가 v3를 가리키고 있었지만 reset --soft 명령어를 통해 v2를 가리키도록 변경되었다. 그 결과 두번째 이미지처럼 head는 v2를 가리키고, index와 working directory는 v3를 가리키게 된다. 

 

 

mixed 옵션

위의 경우처럼 soft 옵션을 사용하면 HEAD와 Index, Working Directory 간의 차이가 버전차이가 발생한다. mixed 옵션을 사용하면 아래 그림처럼 HEAD와 INDEX 까지의 버전을 맞출 수 있다. HEAD 가 가리키는 커밋 버전을 이전 버전으로 변경하고 INDEX도 옮겨진 HEAD 기준으로 업데이트된다.

 

 

hard 옵션

예상할 수 있듯이 hard 옵션은 옮겨진 헤드 기준으로 HEAD, Index, Working Directory가 전부 변경되는 옵션이다. 즉 커밋한 이력이 없는 Working Directory의 작업 내용이 전부 사라지기 때문에 매우 매우 주의해서 사용해야 한다.

 

예를 들어 초기상태(HEAD가 v3를 가리키는 상태)에서 개발을 한참 진행하다가 reset --hard 명령어를 실행했다? 그러면 개발한 내용이 전부 날아가는 끔찍한 상황이 발생하는 옵션인 것이다.

 

---

참고 

https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-Reset-%EB%AA%85%ED%99%95%ED%9E%88-%EC%95%8C%EA%B3%A0-%EA%B0%80%EA%B8%B0

Git - Reset 명확히 알고 가기