Pro Git (3) - 브랜치 part 1

Git 브랜치 (1)

모든 버전 관리 시스템은 브랜치를 지원한다.

개발을 하다 보면 코드를 여러 개로 복사해야 할 일이 자주 생기는데, 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발할 수 있게끔 브랜치가 도와준다.

Git의 브랜치는 다른 것들과 구분되는 특징이라고도 한다.

브랜치가 매우 가벼워서, 순식간에 브랜치를 새로 만들고 브랜치 사이를 이동할 수 있다.

브랜치란?

Git은 커밋을 하면 현재 Staging Area에 있는 데이터의 스냅샷에 대한 포인터, 저자나 커밋 메시지와 같은 메타데이터, 이전 커밋에 대한 포인터 등을 포함하는 ''커밋 Object'를 저장한다.

이전 커밋 포인터가 있어서 현재 커밋이 무엇을 기준으로 바뀌었는지 알 수 있다.

Blob

: 파일을 Stage하고 Git 저장소에 파일을 저장하는 것

ex) 파일 3개 있는 하나의 디렉토리를 Staging Area에 저장하고 커밋하는 예제

1. Blob

2. Staging Area에 해당 파일의 체크섬을 저장

3. git commit => 루트 디렉토리와 각 하위 티렉토리의 트리 개체를 체크섬과 함께 저장소에 저장

4. 커밋 개체(Object) 만들고 메타데이터와 루트 디렉토리 트리 개체를 가리키는 포인터 정보를 커밋 개체에 넣어 저장 (필요하면 언제든 스냅샷 다시 만들 수 있음)

5. 이 작업을 마친 뒤에는 Git 저장소에 다섯 개의 데이터 개체가 생성됨

   1. 각 파일에 대한 Blob 세 개

   2. 파일과 디렉토리 구조가 들어있는 트리 개체 한 개

   3. 메타데이터와 루트 트리를 카리키는 포인터 담긴 커밋 개체 한 개

      

브랜치가 가리키는 히스토리 조회

git log 명령을 이용하여 쉽게 확인 가능하다.

git log --oneline --decorate --graph --all이라고 실행하면,

현재 브랜치가 가리키는 히스토리가 무엇이며 어떻게 갈라져 나왔는지 보여준다.

브랜치와 Merge의 기초

실제 개발 과정에서 겪을 수 있는 예제를 살펴보자.

1. 작업 중인 웹 사이트 존재
2. 새로운 이슈 처리를 위한 Branch 생성
3. 새로 만든 Branch에서 작업 진행

이 때, 중요한 문제가 생겨 그것을 해결하는 Hotfix를 먼저 만들어야 한다면?

1. 새로운 이슈 처리 이전에 운영(Production)하던 Branch로 이동
2. Hotfix 브랜치를 새로 생성
3. 수정한 Hotfix 테스트를 마친 뒤 운영 브랜치로 Merge
4. 다시 작업하고 있던 브랜치로 옮겨 마저 작업 진행

이제까지 해 온 프로젝트에서 수도 없이 해 본 과정이다.

git branch 옵션

1. -v : 브랜치마다 마지막 커밋 메시지 보여주기
2. --merged / --no-merged : 현재 브랜치 기준, merge 된 혹은 merge되지 않은 브랜치 보여주기