Git 브랜치
- VCS의 브랜치란 무엇인가요?!
개발을 하다 보면 코드를 여러 개로 복사한 뒤, 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이 브랜치입니다.
특히!
브랜치는 Git의 최고의 장점이라고, Git이 다른 VCS들과 구분되는 특징이라고 합니다.
물론 다른 VCS에도 branch는 존재 합니다. 하지만, Git의 브랜치는 매우 가볍습니다. 브랜치를 새로 만들고 브랜치 사이를 이동할 수 있는 것이 훨씬 더 빠르게 가능합니다.
그 이유에 대해서 알아보겠습니다!
- Git의 branch?!
Git이 브랜치를 다루는 과정을 이해하려면, 우선 Git이 데이터를 어떻게 저장하는지 이해하는 과정이 필요합니다.
Git은 단순히 변경사항을 기록하는 것이 아니라, 일련의 스냅샷으로 기록한다는 것으로 시작합니다!
Git은 커밋을 진행하면, 현 Staging Area에 있는 데이터의 스냅샷에 대한 포인터, 저자나 커밋 메시지 같은 메타데이터, 이전 커밋에 대한 포인터 등을 포함하는 커밋 Object를 저장합니다.
즉, 커밋 객체에는 이전 커밋 포인터가 있어서 현재 커밋이 무엇을 기준으로 바뀌었는지를 알 수 있으며, 최초 커밋을 제외한 나머지 커밋은 이전 커밋 포인터가 적어도 하나씩 있고 브랜치를 합친 Merge 커밋 같은 경우에는 이전 커밋 포인터가 여러 개개가 있을 수도 있습니다! ( 예시, merge -> b1 and merge -> b2)
- 예시
파일이 3개 있는 디렉토리가 하나 있고 이 파일을 Staging Area에 저장하고 커밋하는 예제를 통해 조금 더 깊게 알아보겠습니다.
Git은 파일을 add하면 Blob 형식으로, Staging Area에 해당 파일의 체크섬을 저장합니다.
$ git add README test.rb LICENSE
$ git commit -m 'The initial commit of my project'-
git add가 진행되면, 먼저 루트 디렉토리와 각 하위 디렉토리의 Blob들을 연결하는 트리 개체를 체크섬과 함께 저장소에 저장합니다.
-
그다음에 커밋 개체를 만들고 메타데이터와 루트 디렉토리 트리 개체를 가리키는 포인터 정보를 커밋 개체에 넣어 저장합니다.
이 작업을 마치고 나면 Git 저장소에는 다섯 개의 데이터 개체가 생기는데 이를 사진을 통해서 확인 하겠습니다.
즉, Git의 Snapshot은 커밋 개체를 가리키는 포인터 정보만을 의미하기에, Snapshot간 이동이 훨씬 가볍습니다.
- Snapshot과 branch의 관계
HEAD 포인터 : 현재 작업중인 브랜치를 가르키느 포인터
위 예시를 보면 Git의 브랜치는 단순히 커밋 개체를 가르키고 있는 포인터와 같습니다.
master 브랜치를 기준으로 testing 브랜치를 만들고, 새로운 커밋 개체를 만든 상황에 다시 HEAD 포인터를 master 브랜치로 이동시킨 상황입니다.
그렇다면! master 브랜치에서 역시 수정을 하고 새로운 커밋 개체를 만들면, 어떤 식으로 표현될까요?!
네 보시는 바와 같이 커밋 개체가 하나 더 생기고 f30b Snapshot을 기준으로 두 브랜치가 분기 된 모습이 확인 가능합니다.
그리고 master 브랜치는 가장 최근의 커밋 개체를 가르키는 포인터 뿐임을 알 수 있습니다 👍
이를 CLI를 통해서 확인 하려면, git log 명령어를 통해 확인 가능합니다.
$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) made other changes
| * 87ab2 (testing) made a change
|/
* f30ab add feature #32 - ability to add new formats to the
* 34ac2 fixed bug #1328 - stack overflow under certain conditions
* 98ca9 initial commit of my project- 정리
앞서 설명한 바와 같이, 실제로 Git의 브랜치는 어떤 한 커밋을 가리키는 체크섬 파일에 불과하기 때문에 만들기도 쉽고 지우기도 쉽습니다. 즉 새로운 브랜치를 하나 만드는 것 역시, 40바이트 크기의 체크섬 파일을 하나 만드는 것에 불과하기 때문에, 브랜치가 필요할 때 프로젝트를 통째로 복사해야 하는(수십 초에서 수십 분까지 걸리는) 다른 버전 관리 도구와 Git의 차이는 극명하다고 볼 수 있습니다.
게다가 커밋을 할 때마다 이전 커밋의 정보를 저장하기 때문에 Merge 할 때 어디서부터(Merge Base) 합쳐야 하는지 알기에, Merge 과정이 순조롭게 진행될 수 있습니다.
다음 장은, 이제 왜 그렇게 브랜치를 수시로 만들고 사용해야 하는지에 대해서 읽고 정리하는 시간을 가지겠습니다!!
- 출처
해당 게시글은 Git의 공식 tutorial 문서를 읽고 정리 한 게시글 입니다.
따라서 사진 및 글 내용 역시 좀 더 자세하게 확인하기 위해서 아래 링크를 확인하세요!
