모든 버전 관리 시스템에는 '브랜치(Branch)'라는 개념이 있다.

브랜치는 '나뭇가지'라는 뜻으로, 가지에서 새 줄기를 뻗듯이 여러 갈래로 퍼지는 데이터의 흐름을 가리키는 말로 사용합니다.

브랜치가 필요한 이유

우리가 어떤 제품의 사용 설명서를 만든다고 상상해보자.

사용 설명서의 버전 관리를 깃으로 한다. 제품 출시 전에. 개발 순서에 따라 사용설명서를 작성하지만, 제품이 출시되고나서, 문제가 생긴다면, 고객사마다 추가로 요구하는 내용이 다르다.

모든 요구사항들을 다 반영하다보면, 고객사에 따라 제품이 달라질 것이고, 이에 맞춰 사용 설명서도 달라져야 한다. 이런 경우, 어떻게 해야할까?

→ 제일 먼저, 떠오르는 것은 처음에 작업했던 저장소 전체를 여러 개 복사해서 각 고객사의 이름을 붙인 다음 저장소마다 버전관리를 따로 하는 방법이다.

: 회사마다 똑같은 저장소를 하나씩 주고 회사의 입맛에 맞게 변형하는 구조

하지만, 이 방법은 효율적이지 않다.

1. 고객사마다 디렉터리를 복사하면, 출시 전까지 만들었던 내용은 동일하기 때문에 자료가 중복된다.
2. 버전 관리 시스템의 장점인, 파일이름을 더럽히지 않는 것이 어려워진다. (회사마다 다 다른 디렉터리 이름을 사용하기 때문에)
3. apple에서 작업한 내용이 google에서도 필요하다면, 단순히 최신 상태의 코드를 붙여서 넣으면 가능할까?

→ 문제가 생길 가능성 ↑ / 만약, 'GH'버전을 가져오고 싶어도, 'GE', 'GF'에서 수정한 사항들이 'AE에는 반영되어있지 않기 때문에, 충돌이 날 가능성이 매우 높다!

그렇다고, GG버전 코드 전체를 그대로 덮어버리면, 'D'버전에서 'AE'버전을 만들면서 수정했던 내용들이 의도치 않게 바뀌거나 사라지게 된다.

⇒ 이에 대한, 해결책이 바로 브랜치('branch')이다.

브랜치 기능 살펴보기

깃으로 버전 관리를 시작하면, 기본적으로 'master'라는 브랜치를 만들게 된다. 사용자가 커밋할 때마다, master 브랜치는 최신 커밋을 가리킨다.