Git Branch

모든 버전 관리 시스템은 브랜치를 지원한다고 한다. 개발을 하다 보면 코드를 복사해야 하는 일이 자주 생긴다. 코드를 아니 프로젝트를 통으로 복사하고 나서 원래 기획된 프로젝트 외에 기술을 따로 붙여서 진행할 수도 있는데, 이렇게 독립적으로 개발을 할 수 있는 것이 브랜치이다.

 

왜 사람들은 git의 브랜치가 최고의 장점이라고 하는 것인지 다른 버전 관리 시스템과 git의 차이라고 하는지 알아보자.

 

 

브랜치란 무엇인가?

 

git이 브랜치를 다루는 과정을 이해하기 위해선 git이 데이터를 어떻게 저장하는지 알아야 한다.

앞에서 git이 파일 시스템의 스냅샷으로 기록한다고 말했다. commit을 하면 git은 현 Staging Area에 있는 데이터의 스냅샷에 대한 포인터(c의 포인터라고 생각) , 메타데이터, 이전 커밋에 대한 포인터 등을 포함하는 Commit Object를 저장한다.  그렇기에 현재 커밋이 어떻게 무엇이 바뀌었는지를 알 수 있다. 최초 커밋을 제외한 나머지 커밋을 이전 커밋 포인터가 적어도 하나씩은 있고, 브랜치를 합친 Merge 커밋은 여러 개가 존재한다.

 

git의 브랜치는 커밋 사이를 가볍게 이동할 수 있는 어떤 포인터 같은 것이다.

기본적으로 Git은 커밋할 시 master브랜치를 만든다. 처음 커밋하면 master브랜치가 생성된 커밋을 가리키고, 이후 커밋을 만들면 master 브랜치는 자동으로 가장 마지막 커밋을 가리킨다.

 

master는 가장 마지막 커밋을 가리킨다.

 

브랜치를 생성해보자.

git branch testing

 

새로 만든 브랜치도 마지막 커밋을 가리킨다.  지금 작업 중인 브랜치가 무엇인지 git은 어떻게 파악할까? 

git은 HEAD라는 특수 포인터를 가지고 있다.  이 포인터는 지금 작업하는 로컬 브랜치를 가리킨다. 

우리가 작성한 git brach명려는 브랜치를 만들기만 하고 옮기지는 않는다.

 

 

 

이 브랜치가 어떤 커밋을 가리키는지 알고 싶으면 git log --decorate 옵션을 사용해보자

현재 master와 testing이라는 브랜치가 어디 커밋에 위치하는지 알 수 있다.

이제 브랜치를 이동해보자 브랜치 이동명령은 다음과 같다.

git checkout testing

이러면 HEAD포인터는 testing을 가리킨다.

 

이제 새로운 파일을 만들고 커밋을 해보자.

초기 master브랜치는 이전 커밋을 가리키고 testing 브랜치가 새로운 커밋을 가리킨다.

이것은 이전 서비스는 그대로 저장하고, 버전 업된 서비스를 개발할 수 있다는 소리이다.

다시 이전 서비스로 돌아가 보자. git checkout master

정말 신기한 게 브랜치를 변경했을 뿐인데 아까 만들었던 newfile이 사라졌다. 진짜 미친 거다. 워킹 디렉터리까지 영향을 미친다는 이야기다.

 

실제로 Git의 브랜치는 어떤 하나의 커밋을 가리키는 SHA-1 체크섬 파일에 불과하기 때문에 만들기도 쉽고 지우기도 쉽다. 41바이트 크기의 파일 하나를 만드는 것이 브랜치를 만드는 것이다. 게다가 커밋을 할 때마다 이전 커밋의 정보를 저장하기 때문에 Merge 할 때 어디서부터 합쳐야 하는지 알고 있다. 이러한 특징은 개발자를 편하게 이동하게 해 준다.