일단 시작하는 Git (5)

Do_Doolly·2022년 2월 5일

형상관리 도구

목록 보기

5/11

글에 적은 내용 중 잘못된 부분은 댓글로 적어주시면 감사하겠습니다!

🔜 타임머신 준비

맨 처음에 Git을 소개할 때, Git은 컴퓨터 세상에서 타임머신과 같은 역할을 한다고 했다. 물론 Git을 사용하는 이유가 단순히 파일을 복원하고 되돌리는 것만이 목적은 아니지만, 이번 시간에는 왜 타임머신이라고 불렀는지 여러 방법으로 Git을 사용해보겠다.

$ git log

Git 테스트 파일이 있는 폴더에 들어가서 터미널에 위와 같이 입력해서 Git 로그를 찾아본다. 지난 시간 이후로 따로 커밋한 게 없다면, 아래와 같이 세 개의 로그가 보일 것이다. 그 동안은 세 개의 파일만을 다뤘는데, 파일 몇 개를 더 만들어서 커밋해보자.

1. 둘리가 파일 두 개 생성 후 각각 커밋

$ touch doolly_1.txt
$ git add -A
$ git commit -m “둘리 파일1 생성”
# 곧이어 파일 생성
$ touch doolly_2.txt
$ gid add -A
$ git commit -m “둘리 파일2 생성”

2. 희동이가 파일 한 개 생성 후 커밋

$ touch heedong_1.txt
# “중요내용 작성 1” 라고 heedong_1.txt에 작성
$ vim heedong_1.txt
$ git add -A
$ git commit -m “희동 파일1 생성”

3. 둘리 파일2 삭제 및 희동 파일1 수정 후 커밋

$ rm doolly_2.txt
# “중요내용 작성 2”라고 heedong_1.txt에 작성
$ vim heedong_1
# -am 옵션은 파일을 바로 staging area에 add 후 커밋 하는 것
$ git commit -am “둘리 파일2 삭제 및 희동 파일1 수정”

4. 둘리 파일3 생성 및 희동 파일1 삭제 후 커밋

$ touch doolly_3.txt
$ rm heedong_1.txt
$ git add -A
$ git commit -m “둘리 파일3 생성 및 희동 파일1 삭제(?)“

Git 로그를 보면 아래와 같을 것이다.

$ git log --oneline

🧐 타임머신 테스트

자 이제 준비는 다 끝났으니 여러 상황을 가정하고 커밋을 왔다갔다 해보자. 실제로 일할 때는 이렇게 형상관리할 일은 없으니, 지금은 그저 예시라고만 생각하자. 최신 상태의 파일 목록은 아래와 같다. 이 상태를 베이스로 둔다.

1. 파일 복원

베이스 상태에서 희동 파일1이 삭제된 건 실수였다고 하면, Git Reset을 이용해서 가장 최근에 작성된 희동 파일1이 있는 곳으로 옮기면 된다. 로그에 나와있는 commit ID를 복사해서 리셋해보면, 희동 파일을 다시 복원할 수 있다.

# 각자 컴퓨터에 있는 commit ID를 입력
$ git reset --hard (commit ID)

폴더에 들어가보면 희동 파일1이 원래되로 복귀된 걸 알 수 있다.

2. 작업상태 원상복귀

베이스 상태에서 둘리 파일2가 중요한 작업이었고, 희동 파일1은 중요하지 않다고 하자. 둘리 파일2의 commit ID를 입력해서 reset하면 그 동안 진행된 커밋이 모두 삭제되고 둘리 파일2가 생성된 상태로 돌아간 것을 알 수 있다.

# “둘리 파일2 생성”의 commit ID를 입력
$ git reset --hard (commit ID)

3. 미래로 복귀

2번 상태에서 다 의미없고, 알고보니 희동 파일1에 중요 내용은 무조건 살려야 한다고 하자. ~~이런..~~ 이 폴더의 시점에서 봤을 때는 과거로 파일을 복원시켰다가, 다시 미래로 돌아가는 느낌이다. 그래서 reset으로 되돌아가려고 로그를 봤더니

헐… 이전에 삭제한 커밋이 보이지 않는다. 당연하겠지만, 방금까지 Reset으로 신나게 커밋들을 삭제했기 때문에, 로그에 삭제한 커밋들이 보이지 않는 것이다. 그러면 이전에 파일을 만들고 수정했던 작업을 또 다시 진행해야할까? 다행히도 Git에는 삭제된 커밋을 다시 찾아볼 수 있다.

$ git reflog

위와 같이 터미널에 입력하면, 그 동안 봐왔던 로그와 사뭇 다를 것이다. 사람마다 어떤 작업을 했느냐에 따라 다르게 보이겠지만, 이 리스트를 잘 찾아보면 아래와 같이 이전에 만들었던 커밋이 보일 것이다.

다행이다! 이제 “둘리 파일2 삭제 및 희동 파일1 수정” 메세지의 commit ID를 복사해서 다시 reset 해보면

# 돌아가려는 삭제된 commit의 ID
$ git reset —hard (commit ID)

로그로 봤을 땐 없던 커밋들이 다시 되살아 난 것을 알 수 있다.

🔚 실제로는

지금까지 타임머신이라 표현한 Git Reset은 실제로는 조심히 써야 한다. 파일을 복원시키거나 커밋을 없애겠다고 마구잡이로 썼다간, 내가 작성한 파일들이 순식간에 사라져서 어떻게 다시 되살려야할 지 머릿속이 하얘질 수도 있다.🥲 reflog도 계속 믿을 순 없다. 어디까지나 Git의 garbage collection에서 로그를 보관중일 때만 가능하다. (기본적으로 90일 정도 보관 후 필요없는 커밋과 데이터는 삭제된다.)
조금은 정신없이 Git Reset까지 달려왔다. 다음에는 지금까지 나온 내용들을 리뷰하면서 나중에 설명한다고 넘어갔던 내용들을 다시 살펴보자.