[Git/Github] Git 기본 명령어2 — reset(이전 버전으로 돌아가기)

dEpayse
dEpayse_publication
7 min readFeb 27, 2022

지난 포스트에서 두 개의 파일을 추가하고, Staging Area에 올린 후에 버전을 생성하는 과정을 보았다. 이번 포스트에서는 이 과정을 다시 한 번 훑으며, 이전 버전으로 되돌리는 방법에 대하여 알아보자. commit을 생성하는 것이 어려운 분은 아래 포스트를 참고하세요!

Fig1. git 파일의 영역과 상태

지난 포스트에서는 add, commit의 과정을 Fig1과 같이 파일의 관점에서 자세히 다루었었다. 이번 포스트에서는 버전을 이동하는 과정을 다루는 것이므로 branch의 관점에서 더 자세히 다뤄보려고 한다.

branch 관점에서 add, commit 과정

이번에도 시작은 git init이 완료된 직후이다. 이 상황에서는 별도로 설정하지 않으면 HEAD 포인터가 master 브랜치를 가리키며, 아무 commit도 생성되지 않은 상태이다. git init과 HEAD 포인터가 생소하다면 아래 포스트를 참고하자!

git init 이후에 first file.txt와 second file.txt 파일을 생성하면 Fig2–1과 같은 상황이 된다.

Fig2–1. git init 이후 로컬 pc에서 파일을 생성하고 저장했을 때

Fig2–1을 보면 추적되지 않는 상태의 두 개의 파일이 Working tree에만 존재한다. Working Tree는 로컬 PC에서의 변화를 말한다.

first file.txt와 second file.txt를 add 명령어를 이용하여 Staging Area에 올리면 Fig2–2와 같은 상황이 된다.

Fig2–2. 두 개의 파일을 staging area에 올렸을 때

Fig2–2를 보면 두 개의 파일이 Staged 된 상태인 것을 볼 수 있다. 이 때 commit 명령어를 이용하여 commit을 생성하면 Fig2–3과 같은 상황이 된다.

Fig2–3. Staging Area에 추가된 파일을 올리고 커밋했을 때

하나의 커밋이 생성되었고, master branch가 첫 번째 커밋을 가리키는 것을 볼 수 있다. Fig2–1~Fig2–3까지의 상황을 봤을 때 변화의 순서는 Working tree → Staging Area → HEAD 인 것을 알 수 있다. 이제 파일을 수정하고 두 번째 커밋을 만들어보자.

여기서 first file.txt와 second file.txt를 수정한다면 아래와 같은 상황이 된다.

Fig2–4. 첫 번째 커밋 이후 수정했을 때

Working tree의 두 개의 파일이 modified 상태로 변한 것을 볼 수 있다. 이 파일들을 add 명령어를 이용하여 Staging Area에 올리면 Fig2–5와 같은 상황이 된다.

Fig2–5. 수정된 파일을 Staging Area에 올렸을 때

여기서 commit 명령어를 이용하여 commit을 생성하면 다시 모든 파일이 unmodified 상태로 된다.

Fig2–6. 두 번째 커밋을 생성했을 때

Fig2–6을 보면 생성한 두 번째 커밋이 부모 커밋(직전 커밋)을 가리키고 있고, 이 branch의 이름은 별도로 설정하지 않았으므로 master이다. HEAD 포인터는 master branch를 가리키고 있으므로, 두 번째 커밋을 생성하면 HEAD도 master와 같이 이동한다.

여기까지 과정이 바로 add, commit을 branch 관점에서 바라봤을 때의 과정이다.

reset

reset은 상단의 add, commit에서 본 이전의 단계로 이동할 수 있게 해주는 명령어이다. soft, mixed, hard 세 가지의 옵션이 있는데, 처음 접한 reset은 매우 헷갈린다. 하지만 add, commit의 과정을 잘 이해한다면, reset의 세 가지 옵션은 그 중 하나의 단계로 돌아가는 것뿐이다. Fig2–6 의 단계에서, 세 가지 옵션을 사용하여 그 전 단계로 돌아가는 과정을 차근차근 알아보자.

Fig3–1. reset — soft

reset --soft는 HEAD만 해당 커밋으로 이동한다. 즉 Fig2–6에서 Fig2–5로 돌아가는 것이다. Working tree와 Staging Area는 그대로이지만, 파일의 상태도 Fig2–5와 같이 Staged된 상태이다.

Fig3–2. reset — mixed

reset --mixed는 HEAD를 해당 커밋으로 이동시키고 index파일(Staging Area)도 해당 커밋의 내용으로 변경한다. 따라서 Working tree는 수정사항을 반영하고 있지만, 변경된 파일들이 Staging Area에 올라와 있지 않다. 즉 Fig2–6에서 Fig2–4로 돌아가는 것이다.

Fig3–3. reset — hard

reset --hard는 HEAD를 해당 커밋으로 이동시키고, index파일(Staging Area)도 해당 커밋의 내용으로 변경하며, Working Tree까지 모두 해당 커밋의 처음 상태로 돌아간다. 해당 커밋이 이루어진 직후의 상태로 모든 것을 돌리는 것이며, Fig2–6에서 Fig2–3으로 돌아가는 것이다. hard 옵션은 Working tree가 변경되며 파일 자체가 변경되는 것이고 복구할 수 없으므로 신중히 사용해야 한다.

정리

이번 포스트에서는 git 으로 commit한 버전을 돌리는 방법에 대해서 branch의 관점에서 add, commit 과정을 훑으며 함께 알아보았다.

  • git reset --soft 는 HEAD만 해당 커밋으로 돌아간다.
  • git reset --mixed는 HEAD와 index까지 해당 커밋으로 돌아간다.
  • git reset --hard는 HEAD, index와 working tree까지 해당 커밋으로 돌아간다.

revert 와 차이점

revert 역시 변경 사항을 되돌리지만, reset 과는 차이가 있다. 이러한 차이에 대해서 더 궁금하다면 위의 링크를 참고하자.

Reference

  1. [Git official — Book] — https://git-scm.com/book/en/v2

--

--

dEpayse
dEpayse_publication

나뿐만 아니라 다른 사람들도 이해할 수 있도록 작성하는, 친절한 블로그를 목표로.