[Git] 성공적인 깃 분기 모델(Git Branching Model) 전략

지난 포스팅에서는 깃의 용어와 비주얼 스튜디오에서 어떻게 사용하는지 소개를 했었습니다.

[Git] 쉽고 빠르게 깃(Git) 이해하기

[Git] Visual Studio에서 깃 랩(GitLab) 사용하기

[Git] Visual Studio에서 깃 랩(GitLab) 사용을 위한 준비

이제 깃이 무엇이고 분기가 무엇인지, 비주얼 스튜디오에서 어떻게 사용하는지는 익혔는데요. 분기는 어떻게 만들어야 할까요? 프로그래밍 작업 중 변수 명 짓기도 골치 아픈데 분기는 이름을 어떻게 짓고 어떻게 운영해 나가야 할까요? 이번 포스팅에서는 이런 분기 모델 생성에 관한 전략 및 관리 방법에 대해 소개하고자 합니다.

참고로 본문의 내용은 'Vincent Driessen'이 작성한 'A successful Git branching model'을 참고하여 필요한 내용만 요약했습니다. 원작자에게 허락을 받은 점도 알려드립니다.

Branching Model

왜 깃인가(Why git)?

중앙 집중식 소스 코드 제어 시스템(Centralized source code control system)과 비교하여 Git의 장, 단점에 대한 자세한 내용은 아래 링크를 참고하세요.

링크: https://git.wiki.kernel.org/index.php/GitSvnComparsion 

GitSvnComparison - Git SCM Wiki

여기에는 아직도 많은 논쟁이 있습니다. 개발자로서, 저는 오늘날 다른 도구보다 Git을 선호합니다. Git은 개발자들이 병합(merging)과 브랜칭(branching)에 대해 생각하는 방식을 바꾸어 놓았습니다. 제가 이전에 사용했던 전통적인 CVS/Subversion에서 병합(merging)과 분기(branching)는 항상 약간 무섭고(병합 충돌 때문에), 이 작업은 가끔씩만 수행하였습니다.

하지만 Git을 사용하면 이러한 행동들의 작업은 매우 간단하며, 일상적인 작업 흐름(workflow)의 핵심 부분 중 하나로 간주됩니다. 즉, Git에서의 병합과 분기는 굉장히 중요하고 자주 사용된다는 의미입니다. 예를 들어, CVS/Subversion 고급 사용자 용 서적에서 분기와 병합은 뒷 부분에 소개되지만, 모든 Git 서적에서는 앞장에서 다루게 됩니다. 그만큼 Git에서의 병합과 분기는 간단하고 쉽게 사용된다는 얘기겠죠?

단순하고 반복적인 특성을 갖기 때문에, 분기와 병합은 더 이상 두려워할 대상이 아닙니다. 버전 관리 도구는 다른 무엇보다도 분기와 병합에 도움이 되어야 합니다.

깃에 대한 얘기는 충분합니다. 이제 개발 모델(development model)에 대해 살펴보겠습니다. 여기서 소개할 모델은 기본적으로 모든 팀 구성원이 소프트웨어 개발 프로세스에 따라야 하는 일련의 절차에 지나지 않습니다.

분산되었지만, 중앙 집중식(Decentralized but centralized)

이 분기 모델에서 사용하는 저장소 설정은 중앙 "truth" 저장소에서 작동합니다. 이 저장소는 중앙으로 간주됩니다(Git은 DVCS이므로 기술적인 수준에서 중앙 repo와 같은 것은 없습니다). 이 이름은 모든 Git  사용자에게 친숙한 이름이므로 이 저장소를 원점(origin)으로 합니다.

Decentralized but centralized

각 개발자는 origin에 pull과 push를 합니다. 중앙 집중식 push-pull 관계외에도, 각 개발자는 다른 피어(peer)에서 sub team을 구성하도록 변경 작업을 수행할 수도 있습니다. 예를 들어, 진행 중인 작업을 origin으로 push 하기 전에, 큰 새로운 기능을 위해 두 명 이상의 개발자와 함께 작업하는데 유용할 수 있습니다. 위 그림에서, Alice와 Bob, Alice와 David 그리고 Clair와 David는 하위팀입니다. 즉, David가 작업 중인 내용을 즉시 origin에 push 할 수도 있고, Clair와 함께 작업한 이후 origin에 push 할 수 있다는 것입니다.

메인 분기(The main branches)

핵심적으로, 개발 모델(development model)은 기존의 모델에서 크게 영감을 받습니다. 중앙 저장소는 두 개의 주요 분기를 가지고 있으며 수명은 무한합니다. 메인 분기로는 master와 develop 분기입니다. 수명이 무한하다는 의미는, 버그 수정이나 기능 확장을 위한 분기는 작업이 끝나면 사라지지만, 이 메인 분기들은 유지 된다는 의미입니다.

Main branches

origin에서 master 분기는 모든 Git 사용자에게 친숙해야합니다. master 분기와 병렬로, develop이라 불리는 다른 분기가 존재합니다. origin/master를 HEAD의 소스 코드가 항상 생산 준비(production-ready) 상태를 반영하는 주요 분기점으로 간주합니다. origin/develop은 HEAD의 소스 코드가 항상 다음 릴리스의 최신 개발 변경 사항을 반영하고 있는 주요 분기점으로 간주합니다. 일부는 이것을 "integration branch"라고 부를 것입니다. develop 분기의 소스 코드가 안정적인 지점에 도달하여 배포할 준비가 되면, 모든 변경 사항을 master로 다시 병합(merge)한 다음 릴리스 번호로 태그를 지정해야 합니다. 이 작업이 어떻게 수행되는지 자세히 논의하겠습니다.

번역이 매끄럽지 않네요. 즉, master는 제품으로 출시될 수 있는, 릴리즈 이력을 관리하기 위해 사용하는 분기입니다. 그리고 develop은 다음 릴리즈 버전을 개발하는 분기이며, 모든 기능 개발과 버그가 수정된 내용이 develop으로 병합되고 이것이 안정적인 상태라면 master에 병합됩니다.

다양한 분기들(Supporting branches)

메인 분기인 master와 develop외에도 개발 모델에는 다양한 분기를 병렬적으로 사용합니다. 팀 구성원 간의 병렬 개발, 기능 추적 용이성, 제품 릴리스 및 제품 문제를 신속하게 해결할 수 있도록 말이죠. 메인 분기와 달리 이러한 분기들은 결국 제거될 것이기 때문에 항상 제한된 수명을 가지고 있습니다.

• Feature branches
• Release branches
• Hotfix branches

각 분기들은 특정한 목적을 가지고 있으며 어떤 지점이 원래 지점이 될 수 있고, 어떤 지점이 병합 대상이 되어야 하는지에 대한 엄격한 규칙이 있습니다. 잠시 후에 더 자세히 다뤄보겠습니다. 기술적 관점에서 이러한 지점이 "special"한 것은 결코 아닙니다. 분기 유형은 우리가 사용하는 방법에 따라 분류됩니다.

기능 분기(Feature branches)

develop 분기로부터 분기되고 develop으로 병합되는 분기를 의미합니다. 새로운 기능을 개발할 때 사용됩니다.

분기 이름:
master, develop, release-*, or hotfix-* 이외
[feature/구현할 기능 요약]
예시) feature/roi

Feature branches

기능 분기(topic 분기라고도 불리는)는 향후 릴리스에 대한 새로운 기능을 개발하는 데 사용됩니다. 기능 개발이 시작할 때, 이 기능은 통합될 대상 릴리스는 그 시점에서 알 수 없는 것일 수도 있습니다. 이 의미는, 기능 분기의 본질은 개발 중인 한 존재하지만 결국 다시 병합되거나(곧 출시될 새로운 기능을 추가하기 위해) 폐기(실망스러운 경우)된다는 것입니다. 기능 분기는 일반적으로 origin이 아닌 개발 저장소에 존재합니다.

출시 분기(Release branches)

develop 분기로부터 분기되고 develop과 master로 병합됩니다.

분기 이름:
release-*
예시) release-1.1

릴리즈 분기는 새로운 제품 출시(production release)의 준비를 지원합니다. 이것은 사소한 버그 수정과 메타 데이터(버전 넘버, 빌드 날짜 등) 같은 것들입니다. 이 모든 작업을 Release 분기에서 수행함으로써 develop 분기는 다음 큰 release의 기능을 제공받을 수 있게 됩니다.

새로운 릴리즈 분기를 develop에서 분리할 수 있는 중요한 순간은 개발이 새로운 릴리즈의 원하는 상태를 반영할 때 입니다. 적어도 현재 시점에서 개발하기 위해 구축될 릴리즈를 대상으로 하는 모든 feature를 병합해야 합니다. 릴리즈 브랜치가 시작될 때 곧 출시될 릴리즈에 이번 버전이 아닌 버전 번호가 할당됩니다. 그때까지 develop 브랜치는 다음 릴리즈에 대한 변경 사항을 반영했지만 릴리즈 브랜치가 시작될 때까지 다음 릴리즈가 결국 0.3 또는 1.0이 될지 확실하지 않습니다. 이 결정은 릴리즈 브랜치 시작 시점에서 이루어지며, 버전 번호 충돌에 대한 프로젝트 규칙에 따라 수행됩니다.

핫픽스 분기(Hotfix branches)

master 분기로부터 분기되고 develop과 master로 병합됩니다.

분기 이름:
hotfix-*
예시) hotfix-1.2

Hotfix branches

핫픽스 분기는 계획되지 않았지만 새로운 생산 릴리즈를 준비하기 위한 것이라는 점에서 릴리즈 분기와 매우 비슷합니다. 프로덕션 버전에서 버그를 즉시 해결해야 하는 경우, 프로덕션 버전을 표시하는 마스터 분기의 해당 태그에서 핫픽스 분기를 분리할 수 있습니다.

즉, 릴리즈한 버전에서 버그가 발견되어 develop 분기에서 수정하고 다시 배포하기에는 시간이 많이 소요되기 때문에, master 분기에서 직접 hotfix 분기를 만들어 수정하고 master에 병합하고 다시 릴리즈한다는 것입니다. 개발 중에 발견된 버그는 다음 릴리즈에도 개선 사항이 포함되어야 하기 때문에 develop에도 병합되는 것입니다.