[Git] 버전 관리 시스템, git

🔊 해당 포스팅은 모두의 리눅스 서적 내용 중 19장에 해당하는 내용을 읽고 개인적인 정리 목적 하에 작성된 글입니다. 포스팅 내용은 해당 서적에 기반하였으며 포스팅에서 사용된 자료는 모두 직접 재구성하였음을 알립니다.

 

버전관리 시스템, git

---

이번 포스팅에서는 버전 관리 시스템 즉, 파일 변경 이력을 관리하는 도구인 git에 대해 알아보려고 한다. 먼저 버전 관리 시스템이 무엇인지 부터 살펴보자. 리눅스 뿐만 아니라 맥, 윈도우를 사용하다 보면 특정 텍스트 파일이나 소스코드 또는 셸 스크립트 파일을 계속해서 추가하거나 변경하는 것이 일반적이다. 하지만 파일 내용을 변경할 때마다 매번 새로운 파일을 만들게 되면 이전 버전의 파일 상태로 돌아가기도 힘들고 파일 수가 계속 많아져 디스크를 차지하는 용량도 점진적으로 커질 것이다.

 

이러한 문제를 해결하기 위해 버전 관리 시스템을 사용하면 수동으로 백업하지 않아도 파일의 변경 이력을 관리할 수 있게 된다. 버전 관리 시스템은 크게 2가지 기능을 갖는데, 첫번째로는 파일은 언제, 누가, 무슨 목적으로 어떤 변경을 가했는지 기록하고 확인할 수 있다. 두번째로는 필요에 따라 과거의 특정 시점으로 파일을 복원할 수도 있다. 이러한 기능을 가진 것이 버전 관리 시스템의 특징이며 버전 관리 시스템에는 여러가지가 있지만 가장 널리 쓰이는 git에 대해 알아보도록 하자.

1. git 설치와 초기 설정

git을 설치하고 초기 설정하는 명령어들에 대해 알아보자. 우선 아래의 명령어로 깃이 설치되어 있는지 확인한 후, 만약 git 명령어를 찾을 수 없다고 하면 yum 또는 apt 계열 명령어를 활용해 git을 설치하자.

 

$ git --version
$ yum install git-core
$ sudo apt-get install git-core

 

다음은 깃을 설치한 후 가장 먼저 해주어야 할 이름과 메일 주소 설정이다. git config 명령어를 활용하면 된다.

 

$ git config --global user.name 'zedd'
$ git config --global user.email 'zedd@example.com'

 

참고로 git config 명령어를 활용해서 git 명령어 사용 시 표준 출력 결과 글자 색깔을 컬러로 만들 수도 있다. 

 

$ git config --global color.ui auto

 

이러한 이름, 이메일, 기타 설정들은 ~/.git/config 라는 파일에 보관된다. 그러면 이제 기본적인 사용법에 대해 알아보자.

1-1. 레포지토리 작성하고 파일 추가하기

먼저 아래처럼 하나의 임의 디렉토리를 만들고 git init 명령어로 리포지터리를 작성해보자. 그리고 숨겨진 파일까지 모두 출력해보면 .git 이라는 이름의 디렉터리가 존재하는데, 이것이 바로 깃 레포지토리의 실체이다.

 

$ mkdir -p ~/git/findgrep
$ cd ~/git/findgrep
$ git init
$ ls -al

 

여기서 .git 이라는 깃 레포지토리는 깃이 관리하는 파일의 이력을 보존하는 공간을 의미한다. 그래서 수정 이력은 전부 이 레포지토리에 기록되며 과거 상태로 돌아갈 때도 이 레포지토리의 내용을 참고하게 된다. 깃이 관리하는 파일이기 때문에 사람이 직접 이것을 편집할 일은 없다.

 

반면에, 이력 관리의 대상이 되는 파일이 놓인 공간이 작업 트리(work tree)라고 한다. 위 예시에서는 findgrep 이라는 이름의 디렉터리 공간이 작업 트리가 되겠다. 해당 공간에서 사람이 편집, 수정, 추가, 삭제 등과 같은 작업을 진행하면 된다.

 

그러면 이제 만든 레포지토리에 파일을 추가해보자. 2가지 명령어가 있는데, 바로 add 와 commit이다. 먼저 add는 깃이 관리할 파일을 추가하는 명령어이다. add 명령어를 날림으로써 해당 파일을 staging 상태로 올려놓게 된다. 참고로 -u 옵션을 지정하면 작업 트리에 기록된 모든 파일이 인덱스(인덱스에 대해서는 아래에서 소개)에 등록된다. 하지만 새로 작성한 파일까지 등록하려면 -A 옵션을 넣어주면 된다.

 

$ git add <파일 이름>

 

이렇게 파일을 staging 상태로 올려놓은 후 commit 명령어를 실행한다. commit은 실제 레포지토리(.git 이름의 디렉토리)에 변경 이력을 추가하는 명령어이며 커밋 시 메세지를 첨가할 수 있다. 참고로 커밋 메세지를 입력할 때(-m 옵션을 넣지 않고 그냥 실행할 때 바뀌는 화면에서) 첫 행은 변경에 대한 요약, 두번째 행은 빈 행, 세번째 행부터 상세 메세지를 입력하면 된다.

 

$ git commit -m "work1 파일 추가"

 

이렇게 하면 깃 레포지토리에 변경 이력이 등록된 것이다. 변경 내용은 버전 하나로 레포지토리(.git 디렉토리)내에 보관된다. 이처럼 어느 시점에서의 프로젝트 상태를 리비젼(revision) 또는 커밋(commit) 이라고 한다. 이렇게 새로운 리비젼을 레포지토리에 등록하는 것을 "커밋한다"라고 표현한다.

 

다음으로는 파일을 한번 더 수정 한 뒤, 수정하기 이전과의 차이를 살펴보도록 하자. 우선 파일을 추가로 수정하고 커밋한 뒤 git diff 명령어로 차이를 확인해보자.

 

git diff 명령어로 차이 확인

 

보면 알겠지만 예전 포스팅에서 알아본 것처럼 리눅스의 diff 명령어의 통일 포맷을 따르는 것을 알 수 있다. 추가로 커밋을 한 이력을 log 명령어로 확인할 수 있는데, 이에 대해서는 이전에 게시했던 포스팅을 참고하도록 하자.

2. 작업 트리(work tree) 와 인덱스(index) 간의 관계

이번 목차에는 add, commit 명령어에 대해 좀 더 자세히 알아보도록 하자. 이를 이해하기 위해서는 작업 트리, 인덱스, 레포지토리의 관계에 대해 알아야 한다. 작업 트리와 레포지토리는 위에서 배웠다. 그렇다면 인덱스란 무엇일까? 작업 트리에 있는 파일의 변경 사항을 레포지터리에 반영하기 전에 일단 인덱스라고 불리는 공간에 배치를 하게 된다. 즉, 인덱스란 커밋하기 전에 레포지터리와 작업 트리 사이에 존재하는 공간이다. 그리고 작업 트리에서 인덱스로 파일을 등록하는 명령어가 바로 git add 명령어이다.

 

add, commit 명령어 동작 시 그림

 

위 그림을 잘 살펴보도록 하자. 가장 왼쪽의 초기 단계에서는 인덱스와 작업 트리 상태가 동일하다. 그리고 A, B file을 편집한다.(A, B file 내용이 편집된 버전을 초록색으로 나타냄) 그리고 add 명령어로 file A만 staging 시킨다. 그렇게 되면 인덱스에서는 file A에 대해서만 변경 사항이 등록된다. 그리고 연이어 commit 을 수행하면 인덱스에 있는 상태가 레포지토리의 변경 이력에 등록되게 된다.

 

참고로 git diff 명령어를 활용해서 작업 트리, 인덱스, 레포지토리 간의 차이를 확인할 수 있다.

 

명령어	의미	특징
git diff	작업 트리와 인덱스 간의 차이를 표시	add할 내용이 무엇인지 재확인하기 위해 자주 사용
git diff --cached	인덱스와 레포지토리 간의 차이를 표시	보통 add를 한 후 commit 하기 전에 실제 커밋될 내용이 무엇인지 확인하는 용도로 자주 사용
git diff HEAD	작업 트리와 레포지토리 간의 차이를 표시	git diff 와 git diff --cached를 합친 차이가 표시되는 것

 

보통은 커밋 하나에는 한 가지 이슈와 관련된 수정 사항만 포함하는 것이 좋다. 만약 한 번에 버그 수정과 신기능 추가 2개를 커밋하려면 별도로 커밋 1개씩 하는 것이 좋다.

3. 실수했을 때 복구하기

버전 관리 시스템의 가장 큰 기능 중 하나는 예전 상태로 쉽게 복구할 수 있다는 점이다. 예전 상태로 복구할 수 있는 방법이 크게 2가지가 있다. 첫 번째로는 commit 하지 않았을 때 복구방법이다. 이 때 작업 트리의 최상위 디렉토리로 가서 아래 명령어를 수행하면 파일의 변경 사항이 모두 복원되며 인덱스에 추가한 내용(add로 staging 시킨 내용)들도 모두 사라지게 된다.

 

$ git checkout HEAD .

 

두번째로는 이미 커밋한 사항을 복구하는 방법이다. revert 명령어를 사용하면 된다.

 

$ git revert <특정 커밋 Object명>

 

revert는 복원을 하는 기능이긴 하지만, 실제로는 복원하려는 커밋을 삭제하는 것은 아니다. 대신 해당 커밋의 변경 사항을 복구하는 새로운 커밋이 만들어지는 것이다. 특히 수정 사항이 많아서 직접 고치기 힘들 때 매우 편리한 기능이다. revert에 대한 자세한 내용은 예전 포스팅을 참조해보도록 하자.

4. 레포지토리 백업 작성하기

이번엔 깃 레포지토리를 백업해놓을 레포지토리를 만들어보도록 하자. 이것이 어떻게 보면 현재 활발히 운영되고 있는 GitHub, Gitlab의 등장 원리라고 할 수 있다. 잘 이해해보도록 하자. 우선 위에서 만든 깃 레포지토리를 백업시켜놓기 위해 다른 경로에다가 backup.git 이라는 이름의 디렉토리를 만들고 그 경로로 이동해 아래 명령어를 수행해보도록 하자. 참고로 보통 백업시켜놓을 디렉토리는 끝에 .git 확장자를 붙이는 것이 관례다.

 

$ mkdir -p ~/git/backup.git
$ cd ~/git/backup.git
$ git --bare init

 

그리고 아까 위에서 만든 레포지토리 경로인 ~/git/findgrep 이라는 디렉토리로 이동해서 커밋 이력을 백업 디렉토리에 전송시켜보자. 이 때는 push 명령어를 사용해야 하는데, 아래 형식으로 사용할 수 있다.

 

$ git push <이력을 받을 레포지토리(백업)> <이력을 보낼 브랜치>:<이력을 받을 레포지토리 브랜치>

 

위 형식을 이용하게 되면 아래 명령어로 적용해볼 수 있다.

 

$ git push ~/git/backup.git master:master

 

이렇게 백업시켜놓은 디렉토리를 활용해서 복원시키고 싶으면 git clone 명령어를 사용하면 된다. 클론을 받은 레포지토리는 백업 원천의 레포지토리의 커밋 이력까지 모두 그대로 옮겨져 있는 것을 볼 수 있다.

 

$ git clone ~/git/backup.git

 

push 명령어를 사용할 때 두 레포지토리의 브랜치가 같다면 한 개만 작성해줘도 무방하다. 또한 push 할 레포지토리의 별명을 설정해줄 수 있는데, 별명을 설정해주는 명령어는 remote 명령어로 작성해줄 수 있다.

 

$ git remote add <별명> <레포지토리 경로>

 

그리고 각 레포지토리 경로에 설정된 별명을 확인할 때는 아래 명령어를 사용할 수 있다.

 

$ git remote -v

 

만약 별명을 origin 으로 지었다고 가정한다면 push 명령어는 아래처럼 축약될 수 있다.

 

$ git push origin master

 

우리가 GitHub을 사용하면서 원격 레포지토리에 push를 할 때 매우 자주 본 명령어이다. 따라서 이 명령어의 기원을 백업 레포지토리를 만들고 관리하는 데서 출발했다고 볼 수 있다.

5. 2인 이상의 작업을 가능하게 하는 공유 레포지토리

이번에는 2인 이상 개발자들이 서로 협업해서 공유하며 개발할 수 있는 공유 레포지토리에 대해 알아보자. 공유 레포지토리는 단지 방금 위에서 배운 백업 레포지토리의 응용이라고 할 수 있다. 우선 공유 레포지토리와 2명의 개인 레포지토리가 있을 때의 관계를 도식화한 그림이다.

 

공유 레포지토리로 2인 이상이 개발할 경우의 관계

 

빨간색, 파란색 글씨는 git 명령어이다. 직전 목차에서 알아본 백업 레포지토리 때와 마찬가지로 개인 즉, User들이 개인 레포지토리에서 수정한 내역을 공유 레포지토리 이력에 반영시키기 위해서 push 명령어를 사용하면 된다. 여기서 다른 점은 User들이 이미 새롭게 반영된 공유 레포지토리에 있는 변경 내용을 개인 레포지토리에 반영시키기 위한 pull 명령어가 존재한다. 이게 무슨 이야기인지 예시를 들어보자.

 

위 그림에서 User 1이 개인 레포지토리에서 A라는 파일을 생성한 후 공유 레포지토리에 push를 하였다. 그리고 몇시간이 지난 후, User 2가 개발을 시작하려고 하는데, User 1이 공유 레포지토리에 A라는 파일을 몇 시간 전에 생성한 이력을 확인했고 User 2는 자기가 맡은 기능을 개발할 때 User 1이 push 해놓은 파일 A가 필요한 상황이다. 그렇다면 User 2는 공유 레포지토리에서 파일 A를 자신 개인 레포지토리에 반영시켜야 한다. 이 때 사용하는 명령어가 pull 이며 pull 명령어는 fetch, merge 명령어를 합친 것이다.

 

먼저 fetch 에 대해 알아보자. User 2는 공유 레포지토리의 이력을 받기 위해 fetch 명령어를 먼저 사용해야 하는데, 사용 방식은 아래와 같다.

 

$ git fetch <이력을 받을 다른 레포지토리>

 

fetch 명령어에서도 레포지토리를 지정할 때 push 명령어 때 처럼 레포지토리의 별명을 지정해서 넣어줄 수 있다. 이렇게 fetch 명령어로 가져온 이력은 원격 추적 브랜치라고 불리는 브랜치에 저장이 된다. 이는 자기 자신(User 2)이 작성한 브랜치가 아니라 공유 레포지토리의 내용을 내려받기 위한 브랜치를 의미한다.

 

이와 반대로 User2가 직접 작성한 브랜치, 예를 들어, 애초부터 존재하는 master 또는 main, 아니면 git branch 명령어로 자기가 임의로 만든 브랜치를 로컬 브랜치라고 한다. 또한 원격 추적 브랜치는 '원격 이름/ 브랜치 이름' 이라는 이름으로 자동으로 만들어진다. 깃을 사용하면서 git 그래프를 살펴보면 origin/dev 이런 형태로 이름이 있는 브랜치를 본적이 있을 것이다. 이것이 바로 원격 추적 브랜치이다. 만약 git 브랜치를 확인하고 싶은데, 원격 추적 브랜치들을 확인하고 싶다라고 하면 -r 옵션을 넣어주면 된다.

 

$ git branch -r

 

fetch 명령어를 수행하면 원격 추적 브랜치가 갱신될 뿐(즉, 다른 레포지토리의 이력을 가져오기만 했을 뿐) User2의 개인 작업 트리나 로컬 브랜치에 이력이 반영된 것은 아니다. 따라서 가져온 이력을 실질적으로 반영시키기 위해서는 git merge 명령어를 실행해야 한다. 만약 이력을 반영하고 싶은 개인 로컬 브랜치 이름이 master 이고, 다른 레포지토리의 이력이 담겨 있는 원격 추적 브랜치 이름이 origin/master 라고 한다면 아래 명령어를 수행 해서 반영시키면 된다.

 

# User2의 터미널 화면이라고 가정
$ git checkout master
$ git fetch origin
$ git merge origin/master

 

이렇게 fetch, merge 명령어 2개를 한번에 수행해주는 일이 잦기 때문에 이 2개를 한번에 수행해줄 수 있는 명령어가 바로 pull 이다.

 

$ git pull <다른 레포지토리> <다른 레포지토리 브랜치>
$ git pull origin master

 

참고로 공유 레포지토리는 협업할 때 사용하면서 이 레포지토리에 접근하는 각 사용자들의 읽기/쓰기 권한이 적절히 설정되어야 한다. 안그러면 누군가 악의를 품고 맘대로 코드를 수정할 수 있기 때문이다. 그래서 이러한 점을 막기 위해 GitHub에서는 자신이 아닌 다른 사람이 자신의 레포지토리에 push를 하게 되면 해당 레포지토리 소유자에게 허락을 맡아야 하는 Pull Request(Gitlab에서는 Merge Request)라는 기능이 존재한다. 또한 공유 레포지토리는 보통 HTTP나 SSH 와 같이 네트워크를 통해 접근이 가능한 곳에 보관하는 것이 일반적이다. 그래야 여러 사람들이 접근 가능하기 때문이다.

 

추가로 책에서는 git branch 관련 명령어와 conflict를 해결하는 내용에 대해서도 다루는데, 이에 대해서는 예전 포스팅에서 다룬 적이 있기 때문에 따로 소개하지 않겠다.

---

이렇게 해서 모두의 리눅스 서적의 모든 내용을 공부하고 블로깅하는 게 끝이 났다. 이미 알았던 내용도 있었고 몰랐던 내용도 있어서 비교적 빠르게 읽어나갈 수 있었다. 아무쪼록 이 글을 읽는 누군가에게는 꼭 도움이 되길 바란다!