[깃&깃허브 입문] 깃으로 버전 관리하기

버전은 깃에서 문서를 수정할 때마다 간단한 메모와 함께 수정 내용을 스냅숏으로 찍어서 저장하는 것을 의미한다.

깃 저장소 만들기

저장소를 만들고 싶은 디렉터리로 이동해서 깃을 초기화하면 그때부터 해당 디렉터리에 있는 파일들을 버전 관리할 수 있다.

깃 초기화하기 - git init

1. 깃 저장소를 만들 디렉터리를 하나 새로 만든다.
    홈 디렉터리에 hello-git이라는 디렉터리를 만든 후, cd 명령을 사용하여 hello-git 디렉터리로 이동

디렉터리 이름은 자유롭게 설정 가능하다.

$ mkdir hello-git
$ cd hello-git

2. hello-git 디렉터리 안의 내용을 확인한다.
    아무것도 만들지 않았기 때문에 파일은 하나도 없다. '.'인 항목은 현재 디렉터리이고 '..' 인 항목은 상위 디렉터리이다.

$ ls -al

3. 이 디렉터리에 저장소를 만들기 위해 깃에 git init 명령을 입력한다.
    깃을 사용할 수 있도록 디렉터리를 초기화하는 것이다.

init은 initialize(초기화하다)의 약자이다.

$ git init

4. ls 명령을 사용해서 디렉터리 안의 내용을 확인한다.
    .git이라는 디렉터리가 생김. 이 디렉터리가 깃을 사용하면서 버전이 저장될 저장소이다.

$ ls -al

---

버전 만들기

프로그램 개발에서는 수정 내용이 쌓이면 새로 번호를 붙여서 이전 상태와 구별한다. 이렇게 번호 등을 통해 구별된 것을 버전이라고 한다.

깃에서 버전이란?

• 깃에서 버전은 문서를 수정하고 저장할 때마다 생기는 것이라고 생각하면 된다.
• 버전 관리 시스템 : 다른 이름으로 저장보다 훨씬 쉽게 버전을 만들고 만든 시간과 수정 내용까지 기록할 수 있는 것
• 깃에서 버전을 관리하면 원래 파일 이름은 그대로 유지하면서 파일에서 무엇을 변경했는지를 변경 시점마다 저장할 수 있다. 그리고 각 버전마다 작업 했던 내용을 확인할 수 있고, 그 버전으로 되돌아갈 수도 있다.

스테이지와 커밋 이해하기

• 작업 트리(working tree)는 파일 수정, 저장 등의 작업을 하는 디렉터리로 작업 디렉터리라고도 한다. 즉, 우리 눈에 보이는 디렉터리가 작업 트리이다.
• 스테이지(stage)는 버전으로 만들 파일이 대기하는 곳이다. 스테이징 영역이라고도 부른다.
• 저장소(repository, 리포지토리)는 스테이지에서 대기하고 있던 파일들을 버전으로 만들어 저장하는 곳이다.
  스테이지 내용은 .git/index 파일에 저장되고 저장소의 내용은 .git/HEAD 파일에 저장된다.

스테이지와 저장소는 눈에 보이지 않는다. .git 디렉터리 안에 숨은 파일 형태로 존재하는 영역이다.

hello.txt 파일 문서를 수정하고 저장하면 그 파일은 작업 트리에 있다. 수정한 hello.txt 파일을 버전으로 만들고 싶을 때 스테이지에 넣는다.

파일 수정을 끝내고 스테이지에 다 넣었다면 버전을 만들기 위해 깃에게 커밋(commit) 명령을 내린다. 커밋 명령을 내리면 새로운 버전이 생성되면서 스테이지에 대기하던 파일이 모두 저장소에 저장된다.

작업 트리에서 빔으로 문서 수정하기

hello-git 디렉터리에 새로운 파일을 만든다.

1. hello-git 디렉터리로 이동한다.
hello-git 디렉터리에서 깃을 초기화했기 때문에 버전 관리를 할 수 있다. 깃 상태를 먼저 확인해야 한다.

$ git status

2. 깃의 상태를 나타내는 메시지의 의미는 아래와 같습니다.

• On branch master : 현재 master 브랜치에 있다.
• No commits yet : 아직 커밋한 파일이 없다.
• nothing to commit : 현재 커밋할 파일이 없다.

3. hello-git 디렉터리에 새로운 파일인 hello.txt를 만들어 준다.

$ vim hello.txt

4. 수정한 문서를 저장하고 편집기를 종료한다.

5. 확인하면 방금 만든 hello.txt 파일이 디렉터리 안에 존재한다.

$ ls -al

6. 상태를 확인해보면 'branch master에 hello.txt라는 untracked files가 있다' 라고 한다.

untracked files는 깃에서 아직 한번도 버전 관리하지 않은 파일을 의미

$ git status

지금까지 작업 트리에서 문서 파일을 만들었다.

수정한 파일을 스테이징하기 - git add

작업 트리에서 파일을 만들거나 수정했다면 스테이지에 수정한 파일을 추가한다.

스테이징 or 스테이지에 올린다 : 깃에서 버전 만들 준비를 하라고 알려주는 것

스테이지에 올리는 것을 인덱스에 등록한다라고도 한다.

1. 깃에서 스테이징할 때 사용하는 명령은 git add이다.

$ git add hello.txt

2. 깃 상태를 확인한다.

$ git status

3. untracked files:이라는 문구가 changes to be committed:로 바뀌어져 있다.
    그리고 hello.txt 파일 앞에 new file: 이라는 수식어가 추가로 나타난다.

수정한 파일 hello.txt가 스테이지에 추가되었다.

스테이지에 올라온 파일 커밋하기 - git commit

파일이 스테이지에 있으면 버전을 만들 수 있다.

깃에서 버전을 만드는 것을 커밋(commit)이라고도 한다. 커밋할 때는 그 버전에 어떤 변경 사항이 있었는지 확인하기 위해 메시지를 함께 기록해 두어야 한다.

1. 깃에서 파일을 커밋하는 명령은 git commit 이다.
    한 칸 띄운 후에 -m 옵션을 붙이면 커밋과 함께 저장할 메시지를 적을 수 있다. 이를 커밋 메시지라고 하며 주로 영어로 작성한다.

$ git commit -m "message1"

2. 커밋 후 결과 메시지를 보면 파일 1개가 변경되었고 파일 1개의 내용이 추가되었다고 나타다.

3. 현재의 깃 상태를 확인한다.

$ git status

4. 결과 메시지를 보면 버전으로 만들 파일이 없고 (nothing to commit) 작업 트리도 수정사항 없이 깨끗하다 (working tree clean)고 나타난다.

5. 저장소에 저장된 버전을 확인할 때는 git log 명령을 사용한다.

$ git log

6. 방금 커밋한 버전에 대한 설명이 나타난다.
    커밋을 만든 사람, 만든 시간과 커밋 메시지가 함께 나타난다. 수정한 파일을 커밋하면 이렇게 수정과 관련된 여러 정보를 함께 저장할 수 있고 필요할 때 확인할 수 있다.

스테이지에 있던 hello.txt 파일의 버전이 저장소에 만들어졌다.

스테이징과 커밋 한꺼번에 처리하기 - git commit -am

commit 명령에 -am 옵션을 사용하면 스테이지에 올리고 커밋하는 과정을 한꺼번에 처리할 수 있다. 단, 한 번이라도 커밋한 적이 있는 파일을 다시 커밋할 때만 사용할 수 있다.

1. 빔에서 hello.txt 파일을 연다.

$ vim hello.txt

2. 빔이 열리면 문서를 수정 후 저장하고 편집기를 종료한다.

3. 한 번 커밋한 파일이라면 git commit 명령에 -am 옵션을 붙여서 스테이징과 커밋을 한꺼번에 처리할 수 있다.

$ git commit -am "message2"

4. 방금 커밋한 버전에 어떤 정보가 들어있는지 확인한다.

$ git log

5. 수정한 hello.txt를 저장한 두 번째 버전의 정보가 message2라는 메시지와 함께 나타난다.

---

커밋 내용 확인하기

버전을 관리하기 위해서 지금까지 어떤 버전을 만들었는지 알 수 있어야 한다. 또한, 각 버전마다 어떤 차이가 있는지도 파악할 수 있어야 한다.

커밋 기록 자세히 살펴보기 - git log

깃에서 자주 사용하는 명령 중 지금까지 커밋했던 기록을 살펴보기 위한 명령인 git log가 있다. git log 명령을 입력하면 지금까지 만든 버전이 화면에 나타나고, 각 버전마다 설명도 함께 나타난다.

• 3번째 줄 commit 이라는 항목 옆에 영문과 숫자로 된 긴 문자열이 나타나는데 이를 커밋 해시(commit hash), 또는 깃 해시(git hash)라고 한다. 이는 커밋을 구별하는 아이디라고 생각하면 된다.
• 커밋 해시 옆에 있는 (HEAD -> master)는 이 버전이 가장 최신이라는 표시이다.
• Author 항목에는 버전을 누가 만들었는지 나타낸다.
• Date에는 버전이 언제 만들어졌는지 나타낸다.
• 그 아래는 작성자가 기록한 커밋 메시지가 표현된다.

git log 명령을 입력했을 때 나오는 정보를 묶어서 커밋 로그라고 부른다.

변경 사항 확인하기 - git diff

큰 규모의 프로그램을 짤 때, 커밋 메시지를 참고해도 구체적으로 어디가 어떻게 수정되었는지 파악하기가 어렵다.

이럴 때 git diff 명령을 사용하면 작업 트리에 있는 파일과 스테이지에 있는 파일을 비교하거나, 스테이지에 있는 파일과 저장소에 있는 최신 커밋을 비교해서 수정한 파일을 커밋하기 전에 최종적으로 검토할 수 있다.

1. 현재 hello.txt 파일에는 숫자 1과 2가 입력되어 있고, 저장소에는 2개의 버전이 저장되어 있다.

2. 빔에서 hello.txt 파일을 열고 기존의 내용 중 '2'를 'two'로 변경한다.

$ vim hello.txt

3. git status 명령을 사용하여 깃의 상태를 확인해보면 hello.txt 파일은 수정되었고, 아직 스테이징 상태가 아니라고 나온다.

$ git status

4. 방금 수정한 hello.txt 파일이 저장소에 있는 최신 버전의 hello.txt와 어떻게 다른지 확인하기 위해 git diff 명령을 사용한다.

$ git diff

5. '-2'는 최신 버전과 비교할 때 hello.txt 파일에서 '2'가 삭제되었다는 의미이다. 그리고 '+two'는 hello.txt 파일에 'two'라는 내용이 추가되었다는 의미이다.

작업 트리에서 수정한 파일과 최신 버전을 비교한 후, 수정한 내용으로 다시 버전을 만들고자 하면 스테이지에 올린 후 커밋한다. 그러나 수정한 내용을 버리고자 하면 git checkout 명령을 사용하여 수정 내용을 취소한다.

---

버전 만드는 단계마다 파일 상태 알아보기

깃에서는 버전을 만드는 각 단계마다 파일 상태를 다르게 표시한다. 그래서 파일의 상태를 이해하면 해당 파일이 버전 관리의 여러 단계 중 어디에 있는지, 그 상태에서 어떤 일을 할 수 있는지를 알 수 있다.

tracked 파일과 untracked 파일

git status 명령을 사용하면 화면에 파일 상태와 관련된 여러 메시지가 나타난다. 작업 트리에 있는 파일은 크게 tracked 상태와 untracked 상태로 나누어진다.

1. 빔에서 hello.txt 파일을 열고 '3'을 추가한 후 저장한다.

$ vim hello.txt

2. 빔에 hello2.txt 라는 새로운 파일을 만든다.

$ vim hello2.txt

3. hello2.txt에 a, b, c, d를 한 줄로 입력한 후 파일 저장하고 종료한다.

4. hello.txt 파일과 hello2.txt 파일 모두 작업 트리에 있다. 어떤 상태인지 확인해준다.

$ git status

5. 앞에서 커밋했던 hello.txt 파일은 'Changes not staged for commit:'이라고 되어 있다. 이는 변경된 파일이 아직 스테이지에 올라가지 않았다는 의미이다. 그리고 파일 이름 앞에 modified: 라고 되어 있어 hello.txt가 수정되었다는 것을 알 수 있다.
    이처럼 깃은 한 번이라도 커밋한 파일의 수정 여부를 계속 추적다. 깃이 추적하고 있다는 의미로 tracked 파일이라고 부른다.
반면 hello2.txt 파일 위에는 'untracked files:'라고 되어 있다. hello2.txt 파일은 한 번도 깃에서 버전 관리를 하지 않았기 때문에 수정 내역을 추적하지 않는다. 그래서 untracked 파일이라고 부른다.

6. 수정했던 hello.txt 파일과 hello2.txt 파일은 모두 git add 명령을 사용해서 스테이지에 올릴 수 있다.

$ git add hello.txt
$ git add hello2.txt

git add 명령 뒤에 파일 이름 대신 마침표(.)를 붙이면 작업 트리에서 수정한 파일들을 한꺼번에 스테이지에 올릴 수 있다.

7. 상태를 확인해보면 마지막 버전 이후에 수정된 hello.txt는 modified:로 표시되고, 한 번도 버전 관리하지 않았던 hello2.txt는 new file:로 표시된다. 또한, tracked 파일이나 untracked 파일 모두 스테이지에 올라온 것을 확인할 수 있다.

8. 해당 커밋에는 hello.txt를 수정한 내용과 새로 만든 hello2.txt 내용이 다 포함된다.

$ git commit -m "message3"
$ git log

9. message3 라는 메시지를 붙인 commit이 있다. 그러나 각 커밋에 어떤 파일들이 관련된 것인지 알 수 없다.

10. 커밋에 관련된 파일까지 함께 살펴보려면 git log 명령에 --stat 옵션을 사용한다.

$ git log --stat

11. 가장 최근의 커밋부터 순서대로 커밋 메시지와 관련된 파일이 나열된다.

버전 관리 중인 디렉터리 안에 버전 관리를 하지 않을 특정 파일 또는 디렉터리가 있다면 .gitignore 파일을 만들어 목록을 지정할 수 있다.

unmodified, modified, staged 상태

한 번이라도 버전을 만들었던 파일은 tracked 상태가 된다. tracked 상태인 파일은 깃 명령으로 파일 상태를 확인하면 현재 작업 트리에 있는지, 스테이지에 있는지 등 더 구체적인 상태를 알려준다. 

깃의 커밋 과정 중에서 tracked 파일의 상태가 어떻게 바뀌는지 확인해보자.

1. hello-git 디렉터리를 살펴보면 hello.txt와 hello2.txt 파일이 있다. 

$ ls -al

2. 깃의 상태와 파일의 상태를 확인한다.

$ git status

3. 작업 트리에 아무 변경 사항이 없다. 'working tree clean' 이라고 나타나면 현재 작업 트리에 있는 모든 파일의 상태는 unmodified, 즉 수정되지 않은 상태이다.

4. hello2.txt 파일을 수정한다.

5. 다시 git status 명령을 실행한다. hello2.txt 파일이 수정되었고 아직 스테이지에 올라가지 않았다고 나타난다. 'Changes not stage for commit:' 이라는 메시지가 나타나면 파일이 수정만 된 modified 상태이다.

$ git status

6. git add 명령을 사용하여 스테이지에 올리고 git status 명령을 실행한다. 'Changes to be committed:' 라는 메시지가 나타나면 커밋 직전 단계, 즉 staged 상태이다.

$ git add hello22.txt
$ git status

7. 스테이지에 있는 hello2.txt 파일을 커밋한다. 그 후, git status 명령을 실행한다. 그러면 수정이 없던 unmodified로 돌아간 것을 볼 수 있다.

$ git commit -m "delete b,c,d"
$ git status

git status 명령으로 파일 상태를 보면 이 파일이 어떠한 상태에 있는지 확인할 수 있다.

방금 커밋한 메시지 수정하기

문서의 수정 내용을 기록해둔 커밋 메시지를 잘못 입력했다면 커밋을 만든 즉시 커밋 메시지를 수정할 수 있다. 가장 최근의 커밋 메시지를 수정하려면 git commit 명령에 --amend를 붙인다. 커밋 메시지가 화면 위쪽에 나타난다.

$ git commit --amend

---

작업 되돌리기

스테이지에 올렸던 파일을 내리거나 커밋을 취소하는 등 각 단계로 돌아가는 방법에 대해 알아보자.

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

• 파일을 수정한 뒤 소스가 정상적으로 동작하지 않는 등의 이유로 수정한 내용을 취소하고 가장 최신 버전 상태로 되돌려야 할 때가 있다. 그러나 수천 줄이 넘는 소스를 수정하는 상황이라면 직접 되돌리는 것이 거의 불가능하다.
• 이럴 때 checkout 명령을 사용하면 작업 트리에서 수정한 내용을 쉽게 취소할 수 있다.

checkout 으로 되돌린 내용은 다시 복구할 수 없다.

1. 빔을 열고 숫자 3을 영문 three로 수정한 후 저장한다.

2. 파일의 상태를 확인하면 hello.txt가 수정은 되었지만 아직 스테이지에 올라가지 않은 상태이다.

$ git status

3. git checkout 명령을 사용하여 수정한 내용을 다시 되돌린다.

$ git checkout -- hello.txt

4. 정상적으로 처리되면 화면에 아무것도 나타나지 않는다. cat 명령을 사용하여 파일 내용을 확인해보면 3이 그대로 남아 있는 것을 확인할 수 있다.

$ cat hello.txt

스테이징 되돌리기 - git reset HEAD 파일 이름

수정된 파일을 스테이징했을 때, 스테이징을 취소하는 방법이다.

1. 빔을 사용하여 hello2.txt를 수정한다.

$ vim hello2.txt

2. hello2.txt를 스테이지에 올린 후 git status 명령으로 파일의 상태를 살펴본다.

$ git add hello2.txt
$ git status

3. git reset 명령을 사용하여 스테이지에서 hello2.txt를 내린다.

HEAD 다음에 파일 이름을 지정하지 않으면 스테이지에 있는 모든 파일을 되돌린다.

$ git reset HEAD hello2.txt

4. 다시 파일의 상태를 확인해보면 파일이 아직 스테이지에 올라가기 전(not staged)으로 돌아온 것을 확인할 수 있다.

$ git status

최신 커밋 되돌리기 - git reset HEAD^

수정된 파일을 스테이징하고 커밋까지 했을 때, 가장 마지막에 한 커밋을 취소하는 방법이다.

1. 빔을 열어서 hello2.txt를 수정한다.

$ vim hello2.txt

2. 스테이징과 커밋을 함께 실행한다. 커밋 메시지는 message4로 한다.

$ git commit -am "message4"

3. message4인 커밋을 확인한다.

$ git log

4. 최신 커밋을 되돌리는 명령이다.
    HEAD^는 현재 HEAD가 가리키는 브랜치의 최신 커밋을 가리킨다.
    git log 명령을 실행했을 때 가장 최신 커밋에(HEAD -> master) 표시가 있다. 이렇게 되돌리게 되면 커밋도 취소되고 스테이지에서도 내려진다. 취소한 파일이 작업 트리에만 남는 것이다.

3개 커밋을 취소하려면 $ git reset HEAD~3처럼 사용한다.

5. 정말 커밋이 취소되었는지 확인하기 위해 git log 명령을 사용한다.

🔔 git reset 명령의 옵션 살펴보기                                                                                             

명령	설명
--soft HEAD^	최근 커밋을 하기 전 상태로 작업 트리를 되돌린다.
--mixed HEAD^	최근 커밋과 스테이징을 하기 전 상태로 작업 트리를 되돌린다. 옵션 없이 git reset 명령을 사용할 경우 이 옵션을 기본으로 작동한다.
--hard HEAD^	최근 커밋과 스테이징, 파일 수정을 하기 전 상태로 작업 트리를 되돌린다. 이 옵션으로 되돌린 내용은 복구할 수 없다.

특정 커밋으로 되돌리기 - git reset 커밋 해시

reset HEAD^ 명령으로 최신 커밋을 되돌릴 수도 있지만 특정 버전으로 되돌린 다음 그 이후 버전을 삭제할 수도 있다.

특정 커밋으로 되돌릴 때는 git reset 명령 다음에 커밋 해시를 사용한다.

1. 빔을 사용하여 rev.txt를 만든다.

$ vim rev.txt

2. rev.txt를 스테이지에 올린 후 "R1" 메시지와 함께 커밋한다.

$ git add rev.txt
$ git commit -m "R1"

3. rev.txt를 더 수정한 후 "R2" 메시지와 함께 커밋한다.

$ vim rev.txt
$ git commit -am "R2"

4. 같은 방법으로 "R3", "R4" 메시지를 넣고 커밋한다. 총 4번의 커밋을 한다.

$ vim rev.txt
$ git commit -am "R3"
$ vim rev.txt
$ git commit -am "R4"

5. git log 명령을 사용하여 확인해보면 4개의 커밋이 있고 각 커밋마다 커밋 해시가 함께 나타나 있다.
    4개의 커밋 중 R2라는 메시지가 붙은 커밋으로 되돌려본다. 즉 R2 메시지가 있는 커밋을 최신 커밋으로 만들 것이다.

커밋 해시는 커밋 ID이다.

$ git log

6. reset에서 커밋 해시를 사용해 되돌릴 때 주의할 점이 있다.
    예를 들어 reset A를 입력한다면 이 명령은 A 커밋을 리셋하는 것이 아니라 최근 커밋을 A로 리셋한다. 즉, A 커밋을 삭제하는 것이 아니라 A 커밋 이후에 만들었던 커밋을 삭제하고,  A 커밋으로 이동하겠다는 의미이다.
    R2 커밋으로 이동하기 위해 git log 명령의 결과 화면에서 R2 커밋의 커밋 해시를 선택한다.

7. HEAD가 방금 복사해서 붙인 커밋 해시 위치로 옮겨짐을 알 수 있다. 즉, 방금 복사해서 붙인 커밋이 가장 최신 커밋이 된 것이다.

$ git reset --hard 복사한 커밋 해시

8. git log 명령을 사용해서 로그 목록을 살펴보면 R4와 R3 메시지가 있던 커밋은 삭제되고 커밋 해시를 복사했던 커밋이 최신 커밋이 되었다.

$ git log

9. cat 명령을 사용하여 rev.txt 파일을 확인해보면 내용에 'b'까지만 있다.

$ cat rev.txt

커밋 삭제하지 않고 되돌리기 - git revert

커밋으로 되돌릴 때 수정했던 것을 삭제해도 된다면 git reset 명령 사용하고 커밋을 되돌리더라도 취소한 커밋을 남겨두어야 할 때는 git revert 명령을 사용한다.

1. 빔을 사용하여 rev.txt를 수정한다.

$ vim rev.txt

2. 수정한 rev.txt를 "R5"라는 메시지와 함께 커밋한다.

$ git commit -am "R5"

3. git log로 버전을 확인해보면 3개의 버전이 있다.

$ git log

4. 가장 최근에 커밋한 R5 버전을 취소하고 R5 직전 커밋 R2로 되돌아가려고 한다. revert 명령의 경우 revert 명령 뒤에 취소하려고 하는 버전, 즉 R5의 커밋 해시를 지정한다.

reset의 경우 되돌아갈 커밋 해시를 지정하고 revert의 경우 취소할 커밋 해시를 지정한다.

$ git revert 복사한 R5 커밋 해시

5. revert 명령을 실행할 때는 깃을 설치할 때 지정했던 기본 편집기가 자동으로 나타나면서 커밋 메시지를 입력할 수 있다.
    어떤 버전을 revert 했는지 나타난다.

6. 실제로 버전이 어떻게 바뀌었는지 git log를 통해 확인하면 R5를 revert한 새로운 커밋이 생겼다.
    그리고 기존의 R5 역시 사라지지 않았다. R5 버전을 지우는 대신 R5에서 변경했던 이력을 취소한 새 커밋을 만든 것이다.

$ git log

7. R5 커밋을 취소한 것이 문서에도 반영되었는지 확인해본다.

$ cat rev.txt