왕초보의 깃 & 깃허브 끝내버리기

Clueless Coder·2022년 2월 23일

git & github

목록 보기

1/1

이 포스트 하나로 깃을 끝내버리자. (정확히는 깃 기초라고 할 수 있겠다)

Do it! 지옥에서 온 문서 관리자 책을 보고 공부한 것을 처음부터 끝까지 기록한다. 유튜브 보고 공부할라 그랬는데 딱히 막 이해가 필요 없는 것들은 그냥 책 보면서 코드 써보고 하는 게 더 빠르고 잘맞는 거 같다. 책은 잘 산 거 같음.
사실 내 지식이 아니니 '그렇다고 합니다'체로 쓰려고 했지만 편의를 위해서 그냥 '그렇다' 느낌으로 쓴다. 가자!

1. 깃 시작하기

깃으로 뭘 할 수 있는데?

버전 관리
백업
협업
이렇게 세 가지를 할 수 있다. 그리고 이 순서대로 공부할 거다. 버전 관리를 알아야 백업도 공부할 수 있고 백업을 공부해야 협업을 할 수 있다.

버전 관리는 뭔가?
내가 코드나 문서를 여러 버전으로 쓸 수 있다. 워드에 과제를 하면서 '초안', '수정본', '최종', '진짜최종', '진짜진짜마지막'... 이런 식으로 문서를 다른 이름 저장하기해서 관리한 적이 분명 있을 것이다. 이런 버전이 너무 많아지면 관리하기 힘들다. 뭘 수정했는지 등등 알 수가 없다. 깃은 이걸 해결한다. 문서를 수정할 때마다 언제, 어떤 것을 수정했는지 편하고 구체적으로 기록하기 위한 버전 관리 시스템이다.
백업은 뭔가?
핸드폰이나 컴퓨터에서 맨날 클라우드에 백업하라고 한다. 백업은 우리 컴퓨터가 고장날 때는 대비해서 다른 컴퓨터에 우리 컴퓨터 자료를 복제해놓는 것이다. 클라우드에 올릴 수도 있고, 별도 디스크에 백업할 수도 있다.
백업 공간을 제공하는 인터넷 서비스 중에 깃 파일을 위한 애들이 있고, 이것들은 원격(온라인) 저장소라고 한다. 가장 많이 쓰이는 게 깃허브다.
협업은 어떻게 하는데?
깃허브 같은 온라인 서비스를 쓰면 여러 사람이 같이 일할 수 있다. 여러 사람들이 원격 저장소를 이용해서 수정한 거 올리고, 다운 받아서 쓰고 이렇게 할 수 있다. 아까 말했듯이 깃은 버전 관리 시스템이다. 그러니까 누가 뭘 어떻게 수정했는지도 관리되니 협업에 아주 좋다.
동시에 이런 생각도 든다. '누가 동시에 같은 파일 수정하면 어떡해?' 깃은 협업하다가 생긴 문제들을 중간에서 정리해 주는 기능도 있다.

깃 프로그램의 종류

깃은 제품이 아니라 제품군이다. 여러가지 깃 프로그램이 존재한다. 깃 프로그램은 깃을 더 편리하게 사용할 수 있도록 해준다. 다른 말로 깃 클라이언트 프로그램이라고도 한다.

깃허브 데스크톱
깃허브에서 제공하는 프로그램이다. 복잡한 깃 사용법을 GUI로 구현한 것이다. 기본 기능 위주라 고급 사용자가 되면 아쉽다.
토터스깃
윈도우 전용이다. 윈도우 탐색기의 빠른 메뉴(파일 우클릭시 나오는 메뉴)에 추가되는 프로그램.
소스트리
기본부터 고급 기능까지.

하지만 우리는 커맨드 라인 인터페이스를 사용해서 깃을 쓴다.

깃 설치

여기 들어가서 다운 받자. 본인 컴퓨터 환경에 맞는 거 설치하자. 나는 윈도우다. 설치가 됐으면 GitBash를 실행해보자. git이라고 쳐보고 아래처럼 깃 명령들에 대한 설명이 쭉 나오면 제대로 설치된 것.

맥은 그냥 터미널 쓰면 된다.

다음은 깃 환경 설정을 해줘야 한다. 깃을 사용하기 전에 사용자 정보를 입력하자. 깃은 버전을 저장할 때마다 그 버전을 만든 사용자 정보도 함께 저장하니 필수다. 그럼 누가 어떤 버전을 만들었는지 파악할 수 있다. 윈도우는 깃배시를 맥은 터미널 창을 열고 아래와 같이 치자.

git config --global user.name "clueless_coder"
git config --global user.email "clueless_coder@email.com"

이게 무슨 말이냐면 git config 명령어로 사용자 정보를 설정할 수 있고, --global 이라는 옵션을 추가해주면 이 컴퓨터의 모든 저장소에서 같은 사용자 정보를 사용하도록 할 수 있다. 따옴표 안에 본인 사용자 명과 아래 줄에서는 본인 사용자 메일을 넣어주자.

좋다. 이제 사용자 설정은 끝이다. 우리는 CLI를 쓴다. 그러니 리눅스 명령어도 좀 알아야 한다.

리눅스 명령어들

1. 현재 디렉터리 보기

여기 보이는 이 물결은 현재 홈 디렉터리에 있다는 소리다. (디렉터리나 폴더가 같은 거다.)
리눅스에서 디렉터리 나타내는 기호:

기호	설명
`~`	홈 디렉터리, 'c/Users/사용자아이디'
`./`	현재 디렉터리
`../`	현재 디렉터리의 상위 디렉터리

다음으로 pwd를 쳐보자. pwd는 print working directory, 즉 현재 경로 출력해보라는 거다.
현재 디렉토리에 어떤 파일이 있는지 알고 싶으면 ls를 치자.
터미널 창이 너무 더러워지면 clear를 치자.

2. 리눅스 명령에 옵션을 추가하기

붙임표(-)와 옵션을 나타내는 글자를 같이 입력하면 된다. 파일과 디렉터리의 상세 정보까지 표시하는 옵션을 추가하려면 ls -l 이렇게 치면 된다. 숨긴 파일과 디렉터리도 표시하고 싶으면 -a를 추가하면 된다. 둘 다 쓰려면 -la 또는 -al 이라고 쓴다. ls -la 이렇게 치면 된다.
ls 명령 옵션으로는 -t(파일 작성 시간순으로 내림차순 표시), -r(파일 정렬 순서를 거꾸로 표시)도 있다.

3. 디렉터리 이동하기

cd .. # 상위 디렉터리로 이동
cd 하위디렉터리명 # 하위디렉터리로 이동
cd ~ # 홈 디렉터리로 이동

4. 디렉터리 만들기

mkdir new_dir # 현재 경로에 new_dir 라는 이름의 새로운 폴더가 만들어짐

5. 디렉터리 삭제하기

rm -r new_dir # -r 옵션을 붙이면 해당 디렉터리의 하위에 있는 것들고 같이 삭제됨

6. 빔(Vim)을 써보자

빔은 리눅스의 기본 편집기다. 윈도우로 치면 '메모장'이다. 메모장을 써도 되지만 터미널에서 계속 일을 하고 있다가 또 메모장 열고 만들고 저장하고 다시 터미널 쓰고 이러기는 시간 낭비다. 그래서 터미널에서 사용할 수 있는 편집기인 빔을 쓰자.

cd Documents
mkdir test
cd test
vim test.txt

여기까지 치면 화면이 아래와 같이 될 것이다. 왼쪽 상단에 커서가 깜빡이고 있을 것이고 왼쪽 하단에는 우리가 만든 파일인 test.txt라는 파일명이 보인다.
여기에 뭘 쳐봐도 입력이 안될 것이다. 왜냐면 빔을 처음 열면 ex 모드로 열리기 때문이다. ex 모드에서는 저장, 종료 같은 것을 하고, 입력 모드에서 텍스트를 입력한다. ex → 입력은 I 또는 A로 전환하고 반대는 esc로 전환한다. I를 누르니 왼쪽 하단에 -- INSERT -- 라고 뜬다. 좋다. 모드가 바뀌었다. 이제 텍스트를 입력해보자. 다 입력했으니 ex 모드로 돌아가자. esc 누른다. 그리고 :을 입력한다. 그럼 커서가 -- INSERT --가 있었던 자리로 간다. :wq를 친다. 그럼 저장(w)과 종료(q)가 실행된다. 각각 따로 해도 된다. ex 모드에서 자주 사용하는 명령:

명령	설명
`:w` 또는 `:write`	저장
`:q` 또는 `:quit`	종료
`:wq`	저장 종료
`:q!`	저장 없이 종료해서 확장자가 .swp인 임시 파일이 생성됨

7. 텍스트 파일 내용 간단히 확인하기

cat test.txt

cat 명령으로 할 수 있는 것들:

명령	설명
`cat 파일`	파일 내용 화면에 표시
`cat 파일1, 파일2, ... 파일n > 새파일`	파일 차례로 연결해서 새 파일 만듦
`cat 파일1 >> 파일2`	파일1 내용을 파일2 끝에 연결

2. 깃으로 버전 관리하기

깃 저장소(레파지토리) 생성하기

이제 깃도 깔았고, 터미널 사용법도 간단하게 알겠다. 그럼 본격적으로 깃을 써보자. (여기서부터 참고 이미지가 맥의 터미널로 바뀐다. 컴퓨터를 다른 거를 써서 그렇다. 내용은 똑같다.)
일단 내 컴퓨터에다가 깃 저장소를 만들면서 기본 개념을 익히자. 저장소를 만들기 원하는 디렉토리로 이동한다. 나는 바탕화면에 git-test 라는 폴더를 만들고 그 안에 hello-git 이라는 디렉토리를 생성하겠다. 현재 디렉토리가 홈 디렉토리라면 아래처럼 치면 된다.

cd Desktop
mkdir git-test
cd git-test
mkdir hello-git
cd hello-git

그럼 이제 깃 저장소를 생성해주자. 깃을 사용할 수 있도록 디렉터리를 초기화하는 것이다.

git init

아래처럼 생성되었다는 메시지가 뜨면 성공이다. (설정에 따라 영어로도 메시지가 뜰 수도 있다; 'Initialized empty Git repository ...') 이제 ls -la를 쳐서 디렉터리에 무슨 변화가 생겼는지 보자.위는 git init을 하기 전이고 아래는 한 후이다. .git이라는 애가 새로 생겼다. 이 디렉터리가 바로 앞으로 깃을 사용하면서 버전이 저장될 저장소(repository)다. 윈도위의 탐색기나 맥의 파인더로 이 hello-git 이라는 폴더를 들어가도 .git은 보이지 않을 거다. 사용자가 실수로 지우지 않도록 숨겨있는 애이라 그렇다. shift + command + . 을 누르면 아래처럼 보일 것이다.

버전 만들기

이제 깃 저장소도 생성했고, 본격적으로 깃을 써보자. 깃은 앞서 버전 관리 시스템이라고 했다. 버전이라는 말은 일상 생활에서도 많이 쓰기 때문에 ("이 버전이 좋아? 저 버전이 좋아?", 게임에서 "새로 나온 버전으로 업데이트하세요" 등등) 무슨 뜻인지는 알 것이다. 프로그램에서는 서로 다른 버전을 1.0.0, 1.0.1 ... 이런 식으로 번호로 구분한다. 1.0.0, 1.0.1 이렇게 버전을 나누는 것은 뭔가 서로 다른 점이 있기 때문일 거다. 즉, 첫번째 버전에서 뭔가를 수정하고 저장해서 두번째 버전이 나오고 이럴 것이다. 깃에서 말하는 버전도 이와 같다. 깃에서 버전은 문서를 수정하고 저장할 때마다 생기는 것이다.

에세이를 쓰는 과제를 한다고 하자. 파일명을 바꿔가면서 '다른 이름으로 저장'하여 계속 수정해나갈 것이다. 각 문서가 버전이다. 그런데 1,000번 수정하고 이 파일들을 다 저장한다고 생각해보자. '초안', '수정본', '아마최종', '진짜최종', '진짜진짜최종', ... , '진짜진짜...진짜최종', '제발최종', '제출본' 이렇게 1000번 다 다른 이름을 만들어서 저장하면, 각 파일에서 뭘 수정했고 그래서 뭐가 달라졌고 기억하는 것이 불가능해진다. 이름을 계속 생각해내는 것도 지칠 것이다. 그러니 이렇게 이름을 바꿔가며 수정하고 저장하는 방법은 비효율적이다. 그래서 깃은 이 방법보다 훨씬 쉽게 버전을 만들고 언제 만들었는지, 뭘 수정했는지까지 기록할 수 있다. 또 깃에서 버전을 관리하면 원래 파일 이름은 그대로 유지한채로 파일에서 뭘 바꿨는지 변경 시점마다 저장할 수 있다. 각 버전마다 작업 내용을 확인할 수도 있고, 그 전 버전으로 돌아갈 수도 있다.

어쨌든 깃은 좋은 버전 관리 시스템이라는 거다.

스테이지와 커밋

그래서 깃에서는 어떻게 이름도 안바꾸고 버전을 만들까? 먼저 우리가 알고 있어야할 몇 가지 공간을 소개하겠다.

1. 작업 트리 또는 작업 디렉토리 (working tree/directory)
작업 트리는 파일 수정, 저장 등의 작업을 하는 디렉터리다. 우리가 만든 hello-git 디렉터리가 작업 트리다.

2. 스테이지(stage) 또는 스테이징 영역(staging area)
버전으로 만들 파일들이 대기하는 곳이다. 내가 작업 트리에서 10개 파일을 수정하고 그 중 4개만 버전으로 만들어주려면 4개만 스테이지에 올려주면 된다.

3. 저장소(repository)
스테이지에서 대기 타고 있던 파일들을 버전으로 만들어서 저장하는 곳이다.

스테이지와 저장소는 보이는 폴더가 아니다. 깃을 초기화했을 때 만들어지는 .git 디렉터리 안에 숨은 파일 형태로 존재하는 영역이다. 그냥 지금은 상상 속에 그런 공간이 있다고 생각하면 된다.

자, 내가 hello.txt라는 파일을 수정하고 저장했다고 하자. 그럼 그 파일은 작업 트리에 있는 것이다. 그리고 이 파일을 버전으로 만들기로 했다. 그럼 스테이지에 올리면 된다. 또 다른 파일도 버전으로 만들어야 겠다 싶으면 이것들도 스테이지에 올리자. 스테이지에 올릴 애들을 다 올려놨다면 버전을 만들면 된다. 이때 깃에게 '커밋'이라는 명령을 내리면 된다. 커밋 명령을 내리면 새로운 버전이 생성되면서 스테이지에 대기하던 파일들이 모두 저장소에 저장된다. 정리하자면,

작업 트리에서 문서를 수정, 저장하고 이 문서를 버전으로 만들어주고 싶다면 스테이지에 올린다.

다른 문서들도 버전으로 만들어주고 싶다면 스테이지에 올려놓는다.

이제 올릴 애들 다 올렸으면 커밋 명령을 내려서 저장소에 저장시킨다!

문서 만들기부터 커밋까지 해보기

이제부터 앞서 언급한 전체 과정을 실제로 해보겠다. 먼저 만들어둔 깃 저장소인 hello-git으로 이동하자.

1. 깃 상태 확인하기

git status

그러면 이렇게 현재 상태를 알 수 있다. 먼저 첫번째 줄은 현재 master 브랜치(브랜치는 일단 저장소에 있는 디렉터리라고 생각하자)에 있고, 두번째 줄은 아직까지 내가 커밋한 파일이 없고 마지막은 커밋한 파일이 없다는 것이다. 그럼 이제 커밋할 새로운 파일을 만들어보자.

2. 작업트리에서 파일 만들기

vim hello.txt

hello.txt 라는 파일을 만들고 이를 커밋까지 해보자. 먼저 파일을 만들어야하니 vim을 이용한다. Vim을 사용하는 방법은 앞서 설명했으니 넘어가고 나는 위와 같이 적은 다음에 파일을 저장 종료했다. ls -la 라는 명령어를 쳐서 파일이 제대로 만들어졌는지 확인해보자. 좋다. 잘 만들어진 것이 보일 거다. 다시 git status로 확인해보자. 추적하지 않는 파일에 hello.txt 가 들어가있다. 깃에서는 아직 한번도 버전 관리를 하지 않은 파일을 '추적하지 않는 파일'('untracked files')이라고 한다.

3. 파일 스테이징하기

이제 만든 파일을 스테이지에 올리자. 이걸 스테이징이라고도 한다. (.git/index 파일에 스테이징 내용을 저장하기 때문세 스테이지에 올리는 것을 인덱스에 등록한다라고도 한다.)

git add hello.txt

git add 올릴파일 형태로 하면 스테이지에 올리게 된다. 그 다음에 git status로 확인까지 해보자. '커밋할 변경 사항:'이라는 애가 새로 생겼다. 영어로는 'changes to be commited:' 라고 뜬다. 그리고 hello.txt 앞에 '새 파일:' (영어로는 'new file:') 이라는 것도 생겼다. 이 새 파일을 앞으로 커밋할 것이라는 소리다.

4. 커밋하기

이제 커밋할 준비가 완료되었다. 커밋할 때는 그 버전에 어떤 변경 사항이 있었는지 간단한 메시지를 함께 기록한다.

git commit -m "message1"

git commit 이라는 명령어로 스테이지에 올려둔 애들을 커밋한다. 근데 이때 -m 이라는 옵션으로 커밋 메시지를 적을 수 있다. 나는 "message1" 라는 문구를 적어주었다. (커밋 메시지는 영어로 하는 것이 좋다) 그리고 git status로 상태까지 확인해본다. 커밋할 사항이 없고(nothing to commit) 작업 트리에 수정사항이 없이 깨끗하다(working tree clean).

5. 커밋 확인하기

git log 로 저장소에 저장된 버전을 확인할 수 있다. 방금 커밋한 버전에 대한 설명이 나온다. 커밋한 사람은 clueless_coder 고 아래는 만든 시간 아래는 message1 이라는 커밋 메시지가 보인다.

한방에 스테이징과 커밋하기

git commit -am

-am 옵션으로 스테이징과 커밋을 한방에 처리할 수 있다. 문서를 다시 열고 수정 사항(문서의 두번째 줄에 2를 추가했다) 만든 다음 'message2'라는 커밋 메시지를 넣어 커밋까지 하고 git log로 저장소에 들어간 버전을 확인해보자. 두번째 커밋 정보가 위쪽에 보인다.

커밋 내용 확인하기

1. `git log`

커밋 기록을 자세히 살펴볼 수 있다. 위의 그림에서 첫 줄부터 순서대로,

커밋 해시: commit 다음에 쓰여진 긴 숫자와 알파벳으로 구성된 문자열. 커밋을 구별하는 아이디라고 생각하자. ((HEAD -> master)는 해당 버전이 최신 버전임을 알려준다.)
작성자 정보
버전을 만든 시각
커밋 메시지

이렇게 한 묶음을 '커밋 로그'라고 한다.

2. `git diff`

diff 에서 눈치챌 수 있듯이 차이를 알려준다.

작업 트리에 있는 파일과 스테이지에 있는 파일을 비교하거나,
스테이지에 있는 파일과 저장소에 있는 최신 커밋을 비교할 수 있다.

hello.txt 파일의 두번째 줄인 2를 two 라고 바꿔보자. 그리고 git status로 확인해보자. hello.txt가 수정되었고, 커밋하도록 정하지 않은 변경 사항(changes not staged for commit)이 있다고 뜬다. 저장소에 있는 최신 버전과 현재 작업 트리에 있는 수정본을 비교해보자.

git diff

빨간색 '-2'은 hello.txt 파일에서 '2' 이라는 애가 삭제되고 초록색으로 표시된 '+two'는 이 파일에 'two'가 추가되었음을 알려준다. 이어질 실습을 위해서 두번째 줄을 다시 '2'로 돌려놓자.

단계별 파일 상태 확인하기 (생략 가능)

깃에서는 버전을 만드는 각 단계마다 파일 상태를 다르게 표시한다. 파일 상태를 이해하면 이 파일이 버전 관리의 어느 단계에 있는지 알 수 있다.

tracked or untracked

작업 트리 파일은 tracked 아니면 untracked 파일로 나뉜다. 한 번이라도 커밋한 파일은 tracked 파일이 되고 그렇지 않으면 untracked다. 아까 만든 hello.txt 는 tracked 파일이다. 새로운 hello2.txt라는 파일을 만들어서 차이를 확인해보자. hello.txt 파일에는 셋째줄에 3을 추가하고 hello2.txt 파일은 새로 만들면서 a,b,c,d를 순서대로 한 줄씩 넣겠다. git status로 확인해보니, hello.txt는 커밋하도록 정하지 않은 변경 사항: 이니 변경은 되었으나 스테이지에 올라가진 않았음을 의미한다. 또 수정함: 이라고 되어있으니 파일이 수정되었음을 알려준다. 깃은 이렇게 한 번이라도 커밋된 파일의 수정 여부는 계속 추적한다. 하지만 hello2.txt는 깃에서 버전 관리를 한 적이 없어서 추적하지 않는 파일: 에 있다.

두 파일을 모두 스테이지에 올리고 확인해보자. 마지막 버전 이후에 수정된 hello.txt 는 수정함: 으로 표시되고, 한 번도 버전 관리하지 않은 hello2.txt 는 새 파일: 로 표시된다.
이제 커밋하자. 커밋 메시지는 'message3'라고 한다. git log 까지 찍어서 확인해보자.
근데 문제는 각 커밋이 어떤 파일이랑 관련되었는지 알 수 없다. 그래서 옵션 --stat 을 추가한다. 이제 각 커밋에서 어떤 파일들을 수정했는지 알 수 있다!

(참고) 버전 관리에서 제외하고 싶은 파일이 있다면

버전 관리에서 제외하고 싶은 파일이나 디렉터리가 있다면, .gitignore 파일을 만들어서 목록을 지정할 수 있다. 빔으로 .gitignore 라는 파일을 만들고 버전 관리 안할 파일, 디렉터리나 특정 확장자를 적어 넣으면 된다. 예를 들어, mytext.txt 라는 파일과 tmp/ 라는 디렉터리, 확장자가 .swp 인 파일들을 모두 버전 관리에서 제외하고 싶다면 아래처럼 하면 된다.

unmodified, modified, staged 상태

한 번이라도 버전을 만들었던 파일은 tracked 상태가 된다. tracked 상태인 파일은 깃 명령으로 파일 상태를 확인하면 더 구체적인 상태를 알 수 있다.

먼저 어떤 파일들이 있나 확인하고 깃 상태를 확인하자
작업 트리에 아무 변경 사항이 없음을 나타낸다. hello2.txt는 unmodified 상태다.
hello2.txt 파일을 수정해보자. a만 남기고 다 삭제하고 다시 상태를 보자.

파일은 수정만된 modified 상태다.
hello2.txt를 스테이지에 올리고 확인하자.
이제 커밋할 변경 사항: 에 있다. 즉, staged 상태다.
스테이지에 있는 hello2.txt를 커밋하고 확인하자.
이제 커밋할 사항이 없다. hello2.txt 는 다시 unmodified 상태가 된다. 간단히 상태들을 정리해보자

작업 트리의 파일들은 tracked 와 untracked로 나뉜다.

버전을 만든 적이 있는 파일은 tracked고 그렇지 않으면 untracked다.

tracked가 되면 깃이 변경 사항을 계속 추적한다.

tracked 파일은 이전 버전에서 수정이 없으면 unmodified, 수정 사항이 있으면 modified, 수정한 것은 스테이지에 올렸으면 staged 상태다.

staged 상태인 애를 커밋하면 다시 unmodified 상태로 돌아간다.

(참고) 방금 커밋한 메시지 수정하기
git commit --amend

작업 되돌리기

작업 트리에서 수정한 파일 되돌리기

git checkout -- 수정을되돌릴파일 # --하고 한 칸을 띄고 파일명

hello.txt 파일 내용 일부를 바꾸고 (3->three) 저장한 뒤 checkout 을 써보겠다. cat 으로 파일 내용을 확인해보니 다시 되돌아간 것을 볼 수 있다.

스테이징 되돌리기

git reset HEAD 파일이름

hello2.txt 파일을 알파벳을 대문자로 바꾸고 스테이지에 올렸다가 다시 내려보겠다.
커밋할 변경 사항: 에 있다가, 커밋하도록 정하지 않은 변경 사항: 으로 돌아왔다.

커밋 되돌리기

git reset HEAD^ # 가장 최근 커밋 하나를 취소한다.
git reset HEAD~n # 가장 최근 커밋부터 되돌릴 n개의 커밋이 취소된다.

가장 최근 커밋을 되돌릴 수 있다. 일단 커밋을 하나 해보고 그 커밋을 되돌려보겠다. hello2.txt 에 B를 다음 줄에 추가하고 저장한 다음 커밋 메시지 message4 와 함께 커밋을 했다. 그리고 git log로 커밋이 취소되었는지 확인해본다.

git reset 명령 옵션

명령 옵션	설명
--soft HEAD^	최근 커밋을 하기 전 상태로 작업 트리를 되돌림
--mixed HEAD^	최근 커밋과 스테이징을 하기 전 상태로 작업 트리를 되돌림. 옵션 없이 할 경우 이게 디폴트
--hard HEAD^	최근 커밋과 스테이징, 파일 수정을 하기 전 상태로 작업 트리를 되돌림. 이 옵션으로 되돌리면 복구 불가

특정 커밋으로 되돌리기

git reset 돌아갈_포인트의_커밋해시

연습을 위해 rev.txt 라는 파일을 만들어서 4번의 커밋을 해보겠다. 알파벳을 하나씩 추가하면서 변경 저장했다. (첫번째 커밋엔 a, 네번째 커밋엔 a,b,c,d 까지)

R2 라는 커밋 메시지가 붙은 커밋으로 되돌려 보자. 이는 가장 최근 커밋이 R2 메시지가 있는 커밋으로 바꿔주는 것이다. 그러니까 4, 3번째 커밋이 취소된다. 이를 위해 2번째 커밋의 커밋 해시를 복사해서 git reset 다음에 붙여넣기하면 된다.
HEAD의 위치가 옮겨졌다! 2번째 커밋이 가장 최근 커밋이 된 것이다.
그렇다면 실제 문서는 어떻게 됐을까?
역시 c, d 는 사라지고 a, b 만 있다.

최소하는 커밋을 삭제하지 않고 되돌리기

git reset으로 커밋을 취소하면 취소한 애들은 삭제된다. 하지만 삭제하지 않고 취소한 커밋을 남겨두어야 할 때가 있다. 이럴 때는

git revert 취소할_커밋해시

를 쓰면 된다. rev.txt 파일에 e를 추가하고 저장한 다음 R5 라는 메시지와 커밋하고 revert 로 취소해보자. 이때 주의할 점은 reset 과 다르게 '취소할' 커밋 해시를 복붙해서 넣어주는 것이다. R5를 취소하고 싶다면 R5 커밋 해시를 복붙한다.

그러면 이렇게 자동으로 편집기가 뜨는데, 추가적으로 적어두고 싶은 메시지가 있으면 적자. 나는 '일시적으로 커밋 보류함' 이라고 적었다.

그러고 git log를 찍어보니 새로운 커밋이 생긴 것을 볼 수 있다. 이는 아까 reset 처럼 가장 최근 커밋이 R2의 커밋 해시를 가진 것이 아니다. 기존 R5 역시 사라지지 않는다. R5에서 변경했던 이력을 취소한 새로운 커밋을 만든 것이다. 쉽게 말해서 R5 이전 상태를 가진 커밋을 새로 해줬다고 생각하면 되겠다.

R5 에서 추가해준 e 가 잘 없어졌는지도 확인하자.
좋다! 여기까지 커밋을 하는 것부터 커밋을 되돌리는 것까지 기본적인 깃의 버전 관리를 다루는 방법을 공부해봤다.