Keep going
깃으로 버전 관리하기 본문
깃에서는 문서를 수정할 때마다 간단한 메모와 함께 수정 내용을 스냅숏으로 찍어서 저장한다.
이것을 '버전'이라고 한다.
◆ 깃 저장소 만들기
저장소를 만들고 싶은 디렉터리로 이동해서 깃을 초기화하면 그때부터 해당 디렉터리에 있는 파일들을 버전 관리할 수 있다.
# 깃 초기화하기 - git init
1. 깃 저장소를 만들 디렉터리를 하나 새로 만들고 홈 디렉터리에 hello-git이라는 디렉터리를 만든다.
그리고 cd 명령을 사용해 hello-git 디렉터리로 이동한다.
2. hello- git 디렉터리 안의 내용을 살펴보기 위해 'ls-la' 명령을 입력한다.
화면에 두줄짜리 결과가 나타날 것이다.
마침표가 하나(.)인 항목은 현재 디렉터리를 나타내고,
마침표가 두개(..)인 항목은 상위 디렉터리를 나타낸다.
아직 아무것도 만들지 않았기 때문에 파일은 하나도 없다.
3. 이 디렉터리에 저장소를 만들기 위해 깃에 git init 명령을 입력한다.
깃을 사용할 수 있도록 디렉터리를 초기화하는 것이다.
'Initialized empty Git reposistory...' 라는 메시지가 나타나면 이제부터 해당 디렉터리에서 깃을 사용할 수 있다.
4. ls 명령을 사용해서 다시 한번 디렉터리 안의 내용을 확인해 보겠다.
처음에 살펴봤을 때와는 다르게 '.git'이라는 디렉터리가 생겼다.
이 디렉터리가 깃을 사용하면서 버전이 저장될 '저장소'이다.
# .git은 감춰져 있다. 사용자가 실수로 .git 디렉터리를 지우지 않도록 숨어 있기 때문이다.
윈도우 탐색기에서는 [보기]탭에서 '숨긴 항목'을 체크하고 확인할 수 있다.
◆ 버전 만들기
프로그램 개발에서는 수정 내용이 쌓이면 새로 번호를 붙여서 이전 상태와 구별한다.
이렇게 번호 등을 통해 구별된 것을 버전이라고 부른다.
# 깃에서 버전이란
깃에서 버전이란 문서를 수정하고 저장할 때마다 생기는 것이라고 생각하면 쉽다.
예를 들어 보고서를 작성할 때 '초안'이라는 이름으로 저장했다고 가정하고 보고서를 수정하면서 수정 전 내용을 보관해야 할 경우가 있다. 이럴 때는 보통 '수정'처럼 파일 이름을 바꿔서 저장한다.
그런데 만약 1000개가 넘는 문서의 수정 내용을 이런 방식으로 저장한다고 하면 어떤 파일에서 어떤 내용을 수정했는지 기억할 수 없을 것이다.
이렇게 파일을 다른 이름으로 저장해 버전을 만드는 방법보다 훨씬 쉽게 버전을 만들고 만든 시간과 수정 내용까지 기록할 수 있는 것이 바로 깃과 같은 버전 관리 시스템이다.
깃에서 버전을 관리하면 원래 파일 이름은 그대로 유지되면서 파일에서 무엇을 변경했는지를 변경 시점마다 저장할 수 있다. 또 각 버전마다 작업 했던 내용을 확인할 수 있고, 그 버전으로 되돌아갈 수도 있다.
# 스테이지와 커밋 이해하기
깃은 어떻게 파일 이름은 그대로 유지하면서 수정 내용을 기록하는 것인가?
작업 트리
그림에서 가장 왼쪽에 있는 작업 트리는 파일 수정, 저장 등의 작업을 하는 디렉터리로 '작업 디렉터리' 라고도 한다.
앞에서 만들었던 hello-git 디렉터리가 작업 트리가 된다.
즉 우리 눈에 보이는 디렉터리가 바로 작업 트리다.
스테이지
스테이지는 버전으로 만들 파일이 대기하는 곳이다.
스테이지 역역이라고도 부르기도 한다.
예를 들어 작업 트리에서 10개의 파일을 수정했는데 4개의 파일만 버전으로 만들려면 4개의 파일만 스테이지로 넘겨주면 된다.
저장소
저장소는 스테이지에 대기하고 있던 파일들을 버전으로 만들어 저장하는 곳이다.
스테이지와 저장소는 눈에 보이지 않는다.
깃을 초기화했을 때 만들어지는 .git 디렉터리 안에 숨은 파일 형태로 존재하는 영역이다.
깃이 버전을 만드는 과정
1. 작업트리에서 문서 수정하고 저장한다.
2. 수정한 파일 중 버전으로 만들고 싶은 것을 스테이지에 저장
3. 파일 수정을 끝내고 스테이지에 있는 파일들을 버전으로 만들기 위해 깃에게 '커밋(commit)' 명령을 내린다.
커밋 명령을 내리면 새로운 버전이 생성되면서 스테이지에 대기하던 파일이 저장소에 저장된다.
# 작업 트리에서 빔으로 문서 수정하기
1. hello-git 디렉터리로 이동한다. 위에서 hello-git 디렉터리에서 깃을 초기화했기 때문에 버전 관리를 할 수 잇다.
먼저 깃 상태를 확인하기 위해 git status를 입력한다.
2. 깃의 상태를 나타내는 메시지가 나타난다.
- On branch master : 현재 master 브랜치에 있다.
- No commits yet : 아직 커밋한 파일이 없다.
- nothing to commit : 현재 커밋할 파일이 없다.
3. hello-git 디렉터리에 hello.txt.라는 새로운 파일을 만들어 보겠다.
4. 터미널 창으로 돌아와서 ls-la 명령을 입력한다. 방금 만든 파일이 디렉터리에 만들어졌을 것이다.
5. 다시 git status를 입력해서 깃의 상태를 확인해 보겠다.
branch master에 hello.txt.라는 untracked files가 있다고 한다.
깃에서는 아직 한번도 버전 관리하지 않은 파일을 untracked files라고 부른다.
# 수정한 파일을 스테이징하기 -git add
작업 트리에서 파일을 만들거나 수정했다면 스테이지에 수정한 파일을 추가한다.
이렇게 깃에게 버전 만들 준비를 하라고 알려주는 것을 '스테이징' 또는 '스테이지에 올린다'라고 표현한다.
1. 깃에서 스테이징할 때 사용하는 명령은 git add 이다.
2. 다시 깃 상태를 확인해 본다.
3. untracked files: 이라는 문구가 changes to be commited:로 바뀌었다.
그리고 hello.txt 파일 앞에 'new file:'이라는 수식어가 추가로 나타난다.
'새 파일 hello.txt를 앞으로 커밋할 것이다' 라는 뜻이다.
수정한 파일 hello.txt.가 스테이지에 추가되었다.
스테이지에 올릴 때 경고 메시지가 나타나는 이유
윈도우의 줄바꿈 문자와 리눅스의 줄바꿈 문자가 다르기 때문이다.
개행 문자 또는 eol(end of line)이라고 부르기도 하는 줄바꿈 문자란 텍스트 문서에서 엔터를 눌렀을 때 그 위치에 삽입되는 문자이다.
윈도우에서는 줄이 바뀌는 자리에 CR 문자와 LF 문자가 삽입된다.
그래서 warning:LF will be replaced by CRLF in hello.txt 와 같은 경고 메시지가 나타난다.
이 메시지는 깃에서 자동으로 텍스트 문서의 CRLF 문자를 LF 문자로 변환해서 커밋할 것이라는 의미다.
# 스테이지에 올라온 파일 커밋하기 -git commit
파일이 스테이지에 있다면 이제 버전을 만들 수 있다.
깃에서는 버전을 만드는 것을 간단히 커밋(commit)한다 고도 말한다.
커밋할 때는 그 버전에 어떤 변경 사항이 있었는지 확인하기 위해 메시지를 함께 기록해 두어야 한다.
1. 깃에서 파일을 커밋하는 명령은 git commit이다. 한 칸 띄운 후에 -m 옵션을 붙이면 커밋과 함께 저장할 메시지를 적을 수 있다. 이 메시지를 커밋 메시지라고 한다.
2. 커밋 후에 결과 메시지를 보면 파일 1개가 변경되었고, 파일에 1개의 내용이 추가되었다고 나타난다.
스테이지에 있던 hello.txt. 파일이 저장소에 추가된 것이다.
3. 깃 상태를 확인해보면 버전으로 만들 파일이 없고(nothing to commit) 작업 트리도 수정사항 없이 깨끗하다(working tree clean)고 나타난다.
4. 버전이 제대로 만들어졌는지 확인할까? 저장소에 저장된 버전을 확인할 때는 git log 명령을 사용한다.
5. 방금 커밋한 버전에 대한 설명이 나타난다. 커밋을 만든 사람, 만든 시간과 커밋 메시지가 함께 나타난다.
수정한 파일을 커밋하면 이렇게 수정과 관련된 여러 정보를 함께 저장할 수 있고 필요할 때 확인할 수 있다.
# 스테이징과 커밋 한꺼번에 처리하기 - git commit -am
commit 명령에 -am 옵션을 사용하면 스테이지에 올리고 커밋하는 과정을 한꺼번에 처리할 수 있다.
단, 이 방법은 한 번이라도 커밋한 적이 있는 파일을 다시 커밋할 때만 사용할 수 있다.
1. 빔에서 hello.txt 파일을 열어 입력 모드로 바꾸고 숫자 2를 추가한 후 문서를 저장한다.
2. 앞에서는 수정한 파일을 스테이지에 올리고 커밋하는 것을 git add 명령과 git commit 명령을 사용해서 처리했다.
한 번 커밋한 파일이라면 git commit 명령에 -am 옵션을 붙여서 스테이징과 커밋을 한꺼번에 처리할 수 있다.
3. 방금 커밋한 버전에 어떤 정보가 들어있는지 확인하기 위해 $ git log 를 입력하면 두 번째 버전의 정보가 message2 라는 메시지와 함께 나타난다.
◆ 커밋 내용 확인하기
커밋 기록 자세히 살펴보기 - git log
- 깃에서 자주 사용하는 명령 중 하나가 지금까지 커밋했던 기록을 살펴보기 위한 명령인 git log이다.
- git log 명령을 입력하면 지금까지 만든 버전이 화면에 나타나고, 각 버전마다 설명도 함께 나타난다.
- commit이라는 항목 옆에 영문과 숫자로 된 긴 문자열이 나타나는데 이것을 커밋 해시, 또는 깃 해시라고 한다. 커밋을 구별하는 아이디라고 생각하면 쉽다.
- 커밋 해시 옆에 있는(HEAD -> master)는 이 버전이 가장 최신이라는 표시다.
- Author 항목에는 버전을 누가 만들었는지, Date에는 버전이 언제 만들어졌는지 나타난다.
- 그 아래에는 작성자가 기록한 커밋 메시지가 나온다.
이렇게 git log 명령을 입력했을때 나오는 정보를 묶어 간단히 '커밋 로그'라고 부른다.
변경 사항 확인하기 - git diff
- git diff 명령을 사용하면 작업 트리에 있는 파일과 스테이지에 있는 파일을 비교하거나, 스테이지에 있는 파일과 저장소에 있는 최신 커밋을 비교해서 파일을 커밋하기 전에 최종적으로 검토할 수 있다.
1. 현재 hello.txt 파일에는 숫자 1부터 2까지 입력되어 있고, 저장소에는 2개의 버전이 저장되어 있을 것이다.
2. 빔에서 hello.txt 파일을 열고 기존의 내용 중에서 '2'을 지우고 'two'를 추가한 후 저장한다.
3. git status 명령을 사용해 깃의 상태를 확인해 보면 hello.txt. 파일이 수정되었고, 아직 스테이징 상태가 아니라고 나온다.
4. 방금 수정한 hello.txt 파일이 저장소에 있는 최신 버전의 hello.txt와 어떻게 다른지 확인해 보겠다.
이 경우 git diff 명령을 사용한다.
5. '-2'는 최신 버전과 비교할 때 hello.txt 파일에서 '2'가 삭제되었다는 뜻이고
'+two' 는 hello.txt 파일에 'two'라는 내용이 추가되었다는 뜻이다.
이렇게 작업 트리에서 수정한 파일과 최신 버전을 비교한 다음, 수정한 내용으로 다시 버전을 만들려면 스테이지에 올린 후 커밋하고 수정한 내용을 버리려면 git checkout 명령을 사용해 수정 내용을 취소한다.
◆ 버전 만드는 단계마다 파일 상태 알아보기
깃에서는 버전을 만드는 각 단계마다 파일 상태를 다르게 표시한다.
그래서 파일의 상태를 이해하면 이 파일이 버전 관리의 여러 단계 중 어디에 있는지, 그 상태에서 어떤 일을 할 수 있는지 알수 있다. (파일의 상태가 눈에 보이는 것은 x)
tracked 파일과 untracked 파일
- git status 명령을 사용하면 화면에 파일 상태와 관련된 여러 메시지가 나타난다.
- 작업 트리에 있는 파일은 크게 tracked 상태와 untracked 상태로 나뉜다.
1. 빔에서 hello.txt 파일을 열고 숫자 '3' 을 추가한 후 저장한다.
2. 빔에 hello2.txt 라는 새로운 파일을 만들어 보겠다.
3. hello.txt 파일과 hello2.txt 파일 모두 작업 트리에 있다. git status 명령을 사용해 어떤 상태인지 확인해 보겠다.
4. 앞에서 커밋했던 hello.txt 파일은 'Changes not staged for commit:' 이라고 되어 있다. 변경한 파일이 아직 스테이지에 올라가지 않았다는 뜻이다. 그리고 파일 이름 앞에 modfied: 라고 되어 있어 hello.txt가 수정되었다는 것을 알 수 있다. 이렇게 깃은 한 번이라도 커밋을 한 파일의 수정 여부를 계속 추적한다. 깃이 추적하고 있다는 뜻에서 tracked 파일이라고 부른다.
반면 hello2.txt 파일 앞에는 아무 것도 없고 바로 위에는 'untracked files:' 이라고 되어 있다. hello2.txt 파일은 한 번도 깃에서 버전 관리를 하지 않았기 때문에 수정 내역을 추적하지 않는다. 그래서 untracked 파일이라고 표시한다.
5. 수정했던 hello.txt 파일과 hello2.txt 파일은 모두 git add 명령을 사용해서 스테이지에 올릴 수 있다.
6. git status를 사용해 상태를 확인해 보겠다. 마지막 버전 이후에 수정된 hello.txt는 modified:고 표시되고, 한 번도 버전 관리하지 않았던 hello2.txt는 new file:로 표시된다. 또한 tracked 파일이나 untracked 파일 모두 스테이지에 올라온 것을 확인할 수 있다.
7. 이제 커밋 해보겠다. 이 커밋에는 hello.txt를 수정한 내용과 새로 만든 hello2.txt 내용이 다 포함된다. 성공적으로 커밋이 되었다면 로그를 확인해 보겠다.
8. 'message3'라는 메시지를 붙인 커밋이 보인다. 그런데 각 커밋에 어떤 파일들이 관련된 것인지 알 수 없다.
9. 커밋에 관련된 파일까지 함께 살펴보려면 git log 명령에 --stat 옵션을 사용한다.
가장 최근의 커밋부터 순서대로 커밋 메시지와 관련 파일이 나열된다.
로그 메시지가 너무 많을 경우 한 화면씩 나누어 보여준다. 엔터를 누르면 다음 로그 화면을 볼 수 있고, Q를 누르면 로그 화면을 빠져 나와 다시 깃 명령을 입력할 수 있다.
# .gitignore 파일로 버전 관리에서 제외하기
- 버전 관리 중인 디렉터리 안에 버전 관리를 하지 않을 특정 파일 또는 디렉터리가 있다면 .gitignore 파일을 만들어 목록을 지정할 수 있다. 빔을 사용해서 .gitignore 파일을 만들어 그 안에 버전 관리하지 않을 파일 또는 디렉터리 이름이나 파일 확장자를 입력하면 된다. 주로 개인적으로 메모해 놓은 파일이나 프로그램 사용 중에 자동으로 생성된 swq 파일, 백업 파일 등이 이 목록에 포함된다.
unmodified, modified, staged 상태
- tracked 상태인 파일은 깃 명령으로 파일 상태를 확인하면 현재 작업 트리에 있는지, 스테이지에 있는지 등 더 구체적인 상태를 알려준다.
- 깃의 커밋 과정 중에서 tracked 파일의 상태가 어떻게 바뀌는지 확인해 보겠다.
1. ls 명령을 사용해 hello-git 디렉터리를 살펴보면 앞에서 버전을 저장한 hello.txt 와 hello2.txt 파일이 있다. 여기에서는 hello2.txt 파일의 상태를 따라가 보겠다.
2. git status 명령을 사용해 깃의 상태와 파일의 상태를 살펴보겠다.
작업 트리에 nothing to commit. 'working tree clean'이라고 나타나면 현재 작업 트리에 있는 모든 파일의 상태는 unmodified, 즉 수정되지 않은 상태이다.
3. hello2.txt 파일을 수정해 보겠다. hello2.txt에서 'a'만 남기고 나머지 내용을 삭제한 후 파일을 저장하고 편집기를 종료한다.
4. 다시 git status 명령을 실행한다. hello2.txt 파일이 수정되었고 아직 스테이지에 올라가지 않았다고 나타난다.
'Changes not stage for commit:' 이라는 메시지가 나타나면 파일이 수정만 된 modified 상태이다.
5. git add 명령을 사용해 스테이지에 올리고 git status 명령을 실행해 보겠다. 커밋할 변경 사항이 있다고 한다. 이렇게 'Changes to be commited' 라는 메시지가 나타나면 커밋 직전 단계, 즉 staged 상태이다.
6. 스테이지에 있는 hello2.txt. 파일을 커밋한다. 그리고 git status 명령을 실행한다. 커밋을 끝내고 난 후 hello2.txt 파일의 상태는 수정이 없던 unmodified로 돌아간 것을 볼 수 있다.
지금까지 깃에서 버전을 만드는 과정에서 어느 단계에 있는지에 따라 달라지는 파일 상태를 살펴봤다.
파일의 상태 변화는 다음과 같이 간단한 그림으로 정리할 수 있다.
git status 명령으로 파일 상태를 보면 이 파일이 어느 단계에 있는지 알 수 있을 것이다.
# 방금 커밋한 메시지 수정하기
문서의 수정 내용을 기록해둔 커밋 메시지를 잘못 입력했다면 커밋을 만든 즉시 커밋 메시지를 수정할 수도 있다. 가장 최근의 커밋 메시지를 수정하면 git commit 명령에 --amend를 붙인다.
$ git commit --ammend
명령을 입력하면 기본 편집기인 빔이 실행되면서 원래 커밋 메시지가 화면 위쪽에 나타난다.
◆ 작업 되돌리기
이제부터 스테이지에 올렸던 파일을 내리거나 커밋을 취소하는 등 각 단계로 돌아가는 방법에 대해 알아보겠다.
작업 트리에서 수정한 파일 되돌리기 - git checkout
- 파일을 수정한 뒤 소스가 정상적으로 동작하지 않는 등의 이유로 수정한 내용을 취소하고 가장 최신 버전 상태로 되돌려야 할 때가 있다. 이럴 때 일일히 수정한 소스를 찾아서 직접 되돌려야 한다면 아주 번거로우니, checkout 명령을 사용하면 작업 트리에서 수정한 내용을 쉽게 취소할 수 있다.
1. 먼저 빔을 열고 숫자 '3'을 영문 'three'로 수정한 후 저장한다.
2. git status 명령을 사용해보면 hello.txt 가 수정되었지만 아직 스테이지에 올라가 있지 않다.
그리고 두 번째 괄호 안의 메시지를 보면 작업 트리의 변경 사항을 취소하려면 checkout을 사용하라고 되어 있다.
3. git checkout 명령 다음에 붙임표 2개를 붙이고 한 칸 띈 다음 파일 이름을 쓰면 된다.
4. 정상적으로 처리되면 화면에는 아무것도 나타나지 않는다. hello.txt 파일의 수정 내용이 정말 사라졌을까? cat 명령을 사용해 파일 내용을 확인해 보면 앞에서 '3'을 지우고 'three'를 추가했던 수정 내용이 사라지고 '3' 이 그대로 남아 있는 것을 확인할 수 있다.
스테이징 되돌리기 - git reset HEAD 파일 이름
이번에는 수정된 파일을 스테이징했을 때, 스테이징을 취소하는 방법을 알아보겠다.
1. 빔을 사용해서 hello2.txt를 수정해 보겠다. 기존 내용을 삭제하고 대문자 'A, B, C, D'를 입력한 후 저장하고 빔을 종료한다.
2. git add 명령으로 hello2.txt 파일을 스테이지에 올린 후 git status 명령으로 파일의 상태를 살펴보자
3. git reset 명령을 사용해 스테이지에서 hello2.txt 를 내려보겠다.
$ git reset HEAD hello2.txt
4. 수정된 hello2.txt가 스테이지에서 내려졌다는 메시지가 나타난다.
5. 다시 git status를 사용해 파일의 상태를 확인해 보자. 파일이 아직 스테이지에 올라가기 전으로 돌아온 것을 확인할 수 있다.
최신 커밋 되돌리기 - git reset HEAD^
이번에는 수정된 파일을 스테이징하고 커밋까지 했을 때, 가장 마지막에 한 커밋을 취소하는 방법을 알아보겠다.
1. hello2.txt 문서를 수정해보겠다. 빔을 열고 대문자 'E'를 끝에 추가한 후 저장한다.
2. git commit 명령을 사용해 스테이징과 커밋을 함께 실행한다. 커밋 메시지는 'message4'로 하겠다.
3. git log 명령을 사용하면 커밋 메시지가 'message4' 인 커밋을 확인할 수 있다.
4. 최신 커밋을 되돌리려면 git reset 명령 다음에 HEAD^를 붙인다. HEAD^는 현재 HEAD가 가리키는 브랜치의 최신 커밋을 가리킨다. git log 명령을 실행했을 때 가장 최신 커밋에 표시가 있던 것을 기억할 것이다. 이렇게 되돌리면 커밋도 취소되고 스테이지에서도 내려진다. 취소한 파일이 작업 트리에만 남는 것이다.
$ git reset HEAD^
5. 커밋이 취소되고 스테이지에서도 내려졌다는 메시지가 나타난다.
6. 정말 커밋이 취소됬는지 git log 명령으로 확인해 보겠다. 메시지가 'message4'인 커밋이 사라진 것을 볼 수 있다. 이 방법으로 커밋을 취소하면 이 커밋 전에 했던 스테이징도 함께 취소된다.
# git reset 명령의 옵션 살펴보기
reset 명령을 사용하는 옵션에 따라 되돌릴 수 있는 단계가 다르다.
| 명령 | 설명 |
| --soft HEAD^ | 최근 커밋을 하기 전 상태로 작업 트리를 되돌린다. |
| --mixted HEAD^ | 최근 커밋과 스테이징을 하기 전 상태로 작업 트리를 되돌린다. 옵션 없이 git reset 명령을 사용할 경우 이 옵션을 기본으로 작동한다. |
| --hard HEAD^ | 최근 커밋과 스테이징, 파일 수정을 하기 전 상태로 작업 트리를 되돌린다. 이 옵션으로 되돌린 내용은 복구할 수 없다. |
특정 커밋으로 되돌리기 - git reset 커밋 해시
- 깃에는 파일을 수정하고 커밋할 때마다 저장된 버전들이 쌓여있다.
- 앞에서 살펴본 git reset HEAD^ 명령으로 최신 커밋을 되돌릴 수도 있지만 특정 버전으로 되돌린 다음 그 이후 버전을 삭제할 수도 있다.
- 특정 커밋으로 되돌릴 때는 git reset 명령 다음에 커밋 해시를 사용한다.
1. git reset 명령을 연습해 보기 위해 몇 개의 커밋을 만들어 보겠다.
빔을 사용해 hello-git 디렉터리에 rev.txt를 만든다.
2. rev.txt를 스테이지에 올린 후 'R1' 메시지와 함께 커밋한다.
3. rev.txt를 한 번 더 수정해서 영문자 'b'를 추가하고, 'R2' 메시지와 함께 커밋한다.
4. 같은 방법으로 rev.txt에 영문자 'c'를 추가한 후 'R3' 메시지와 함께 커밋하고, rev.txt에 영문자 'd'를 추가한 후 'R4' 메시지와 함께 커밋한다.
5. git log 명령을 사용해 지금까지 만든 커밋을 확인해 보자. 4개의 커밋이 있고 각 커밋마다 커밋 해시가 함께 나타난다. 여기에서는 R4 메시지가 있는 커밋을 R4 커밋으로, R3 메시지가 있는 커밋을 R3 커밋으로 부르겠다.
이제 4개의 커밋 중 R2라는 메시지가 붙은 커밋으로 되돌려 보겠다. (R2 메시지가 있는 커밋을 최신 커밋으로 만드는 것)
6. reset에서 커밋 해시를 사용해 되돌릴 때 주의할 점이 있다. 예를 들어 reset A를 입력 한다면 이 명령은 A 커밋을 리셋하는 것이 아니라 최근 커밋을 A로 리셋한다. 즉 A 커밋을 삭제하는 것이 아니라 A 커밋 이후에 만들었던 커밋을 삭제하고, A 커밋으로 이동하겠다는 의미다.
R2 커밋으로 이동하기 위해 git log 명령의 결과 화면에서 R2 커밋의 커밋 해시를 선택한다. 그리고 마우스 오른쪽 버튼을 눌러 COPY 를 선택한다.
7. git reset 명령 다음에 --hard 옵션까지 입력한 후 복사한 커밋 해시를 붙여넣는다. 그리고 엔터를 누른다.
$ git reset --hard 복사한 커밋 해시를 붙여넣는다.
→ $ git reset --hard 복사한 커밋 해시
8. HEAD가 방금 복사해서 붙인 커밋 해시 위치로 옮겨졌다고 나타난다. 즉, 방금 복사해서 붙인 커밋이 가장 최신 커밋이 된 것이다.
9. git log 명령을 사용해서 로그 목록을 살펴보자. 우리가 의도했던 대로 R4와 R3 메시지가 있던 커밋은 삭제되고 커밋 해시를 복사했던 커밋이 최신 커밋이 됐다.
10. rev.txt에 'b'를 포함 한 것이 R2, 'c'를 추가한 것이 R3 커밋이었다. R2 커밋으로 되돌렸으니 rev.txt는 어떻게 됬을까 cat 명령을 사용해서 rev.txt 파일을 확인해 보면 내용에 'b'까지만 있을 것이다. 이렇게 R4 커밋과 R3 커밋이 사라지고 , R2메시지가 있는 두 번째 커밋이 최신 커밋이 되었다.
커밋 삭제하지 않고 되돌리기 - git revert
커밋으로 되돌릴 때 수정했던 것을 삭제해도 된다면 git reset 명령을 사용해도 되지만, 나중에 사용할 것을 대비해서 커밋을 되돌리더라도 최소한 커밋을 남겨두어야 할 때가 있다. 이때는 git reset이 아닌 git revert라는 명령을 사용한다.
1. 앞의 내용을 따라왔따면 rev.txt라는 파일에는 영문자 a와 b가 있을 것이다. 커밋은 R2까지 만들어져 있을 것이다. rev.txt 파일을 한 번 더 수정해서 영문자 'e'를 추가한다.
2. 수정한 rev.txt를 'R5'라는 메시지와 함께 커밋한다.
$ git commit -am "R5"
3. git log를 입력해 버전을 확인해 보겠다. rev.txt 파일에 대해 R1과 R2, R5 3개의 버전이 만들어졌다.
4. 가장 최근에 커밋한 R5 버전을 취소하고, R5 직전 커밋 R2로 되돌아가려고 한다. 앞에서 공부했던 reset의 경우에는 R2로 가기 위해서 reset 명령 뒤에 R2의 커밋 해시를 지정했지만, revert 명령의 경우에는 revert 명령 뒤에 취소하려고 하는 버전, 즉 R5의 커밋 해시를 지정한다. 먼저 revert 할 R5 커밋 해시를 복사한다.
5. revert 명령을 실행할 때는 깃을 설치할 때 지정했던 기본 편집기가 자동으로 나타나면서 커밋 메시지를 입력할 수 있다. 커밋 메시지 맨 위에는 어떤 버전을 revert 했는지 나타나 있따. 문서 맨 위에 revert 하면서 추가로 남겨둘 내용이 있다면 입력하고 저장한다.
6. 'R5' 버전이 revert 되었다는 간단한 메시지가 나타나는데, 버전이 어떻게 바뀌었는지 git log를 입력해보겠다.
7. 로그에 R5를 revert 한 새로운 커밋이 생겼다. 그리고 기존의 R5 역시 사라지지 않았따. R5 버전을 지우는 대신 R5에서 변경했던 이력을 취소한 새 커밋을 만든 것이다.
8. 방금 취소한 R5 커밋은 rev.txt 문서에 영문자 'e'를 추가한 것이었다. R5 커밋을 취소한 것이 문서에도 반영되었는지 확인해 보겠다.
앞에서 추가했던 'e'가 없어진 것을 볼 수 있다. 이렇게 revert 명령을 사용하면 버전에 있떤 이력을 취소할 수 있다.
출처 : Do it! 지옥에서 온 문서 관리자 깃&깃허브 입문 [고경희, 이고잉 (이지퍼블리싱)]
