오늘날 거의 모든 버전 제어 시스템은 하나의 중앙 집중식 코드 베이스에서 비롯된 독립적인 작업인 브랜치를 지원합니다. 버전 제어 시스템에 따라 메인 브랜치를 메인 라인, 기본 또는 트렁크라고도 할 수 있습니다. 개발자는 메인 코드 라인에서 자체 브랜치를 만들고 이와 나란히 독립적으로 작업할 수 있습니다.
왜 브랜치가 필요합니까?
브랜치를 사용하면 개발자의 팀이 하나의 중앙 집중식 코드 베이스 내에서 쉽게 협업할 수 있습니다. 개발자가 브랜치를 만들면 버전 제어 시스템은 해당 시점의 코드 베이스의 복사본을 만듭니다. 브랜치의 변경 사항은 팀의 다른 개발자에게 영향을 주지 않습니다. 개발 중인 기능은 불안정할 수 있기 때문에 이는 분명한 장점입니다. 모든 작업이 메인 코드 라인에서 이루어지면 아주 큰 지장이 될 수 있습니다. 그러나 브랜치를 고립시킬 필요는 없습니다. 개발자는 다른 개발자의 변경 사항을 쉽게 끌어와서 기능에 대해 협업하고 비공개 브랜치가 메인 브랜치와 너무 멀리 떨어져 있지 않도록 할 수 있습니다.
브랜치는 기능 작업에만 좋은 것은 아닙니다. 브랜치는 프레임워크, 공동 라이브러리 업데이트와 같은 중요한 아키텍처 변경 사항으로부터 팀을 분리해줄 수 있습니다.
애자일 팀을 위한 3가지 브랜치 전략
브랜치 모델은 팀마다 다른 경우가 많으며 소프트웨어 커뮤니티에서 많은 논란의 주제가 됩니다. 한 가지 큰 주제는 메인으로 다시 병합되기 전에 브랜치에 얼마나 많은 작업이 남아 있어야 하는지입니다.
릴리스 브랜치
릴리스 브랜치란 릴리스가 브랜치 내에 완전히 포함된다는 개념을 의미합니다. 즉, 개발 주기 후반에 릴리스 매니저는 메인에서 브랜치를 만듭니다(예: “1.1 개발 브랜치”). 1.1 릴리스의 모든 변경 사항은 1.1 브랜치에 한 번, 그리고 메인 코드 라인에 한 번 적용하여 총 두 번 적용해야 합니다. 두 브랜치에서 작업하는 것은 팀에 불필요한 추가 업무이며, 두 브랜치에 병합하는 것을 잊어버리기 쉽습니다. 많은 팀원들이 같은 브랜치에서 작업하기 때문에 릴리스 브랜치는 다루거나 관리하기 어려울 수 있습니다. 우리 모두는 모두 하나의 브랜치에 많은 변경 사항을 병합해야 하는 그 고통을 느껴본 적이 있을 것입니다. 릴리스 브랜치를 꼭 해야 하는 경우, 브랜치를 최대한 실제 릴리스에 가깝게 만드세요.
릴리스 브랜치는 시장에 출시된, 버전이 지정된 소프트웨어를 지원하는 데 중요한 부분입니다. 지속적인 개발을 지원하기 위해, 하나의 제품에 여러 릴리스 브랜치(예: 1.1, 1.2, 2.0)가 있을 수 있습니다. 이전 버전(예: 1.1)의 변경 사항을 이후 릴리스 브랜치(예: 1.2, 2.0)에 병합해야 할 수도 있습니다. Git으로 릴리스 브랜치를 관리하는 방법에 대해 자세히 알아보려면 아래 웹세미나를 확인하세요.
기능 브랜치
기능 브랜치는 기능 플래그(제품 내에서 기능을 사용 설정하거나 사용 중지하는 "토글")와 결합되는 경우가 많습니다. 그렇게 하면 코드를 메인에 쉽게 배포하고 기능이 언제 활성화될지 제어할 수 있으므로 기능이 최종 사용자에게 공개되기 훨씬 전에 처음부터 코드를 쉽게 배포할 수 있습니다.
기능 플래그의 또 다른 이점은, 코드를 빌드 내에 유지하면서도 개발 중에는 비활성화할 수 있다는 것입니다. 기능을 사용 설정했을 때 문제가 발생하면 시스템 관리자는 새 빌드를 배포할 필요 없이 기능 플래그를 되돌리고 알려진 양호한 상태로 돌아갈 수 있습니다.
작업 브랜치
Atlassian에서는 작업별 브랜치 워크플로에 중점을 둡니다. 모든 조직에서는 Jira와 같은 이슈 추적기 내에서 작업을 개별 작업으로 자연스럽게 세분화할 수 있습니다. 그러면 이슈가 해당 작업에 대한 팀의 중앙 집중식 연락 지점이 됩니다. 이슈 브랜치라고도 하는 작업 브랜치는 이러한 이슈를 소스 코드에 직접 연결합니다. 각 이슈는 브랜치 이름에 포함된 이슈 키와 함께 자체 브랜치에 구현됩니다. 브랜치 이름에서 이슈 키를 찾기만 하면 어떤 코드가 어떤 이슈를 구현하는지 쉽게 알 수 있습니다. 이렇게 높은 수준의 투명성을 통해, 메인 또는 더 장기적으로 실행되는 레거시 릴리스 브랜치에 특정한 변경 사항을 적용하기가 더 쉽습니다.
애자일은 사용자 스토리를 중심으로 하므로, 작업 브랜치는 애자일 개발에 잘 맞습니다. 각 사용자 스토리(또는 버그 수정)는 자체 브랜치 내에 있으므로 진행 중인 이슈와 릴리스 준비가 된 이슈를 쉽게 확인할 수 있습니다.
이제 브랜치의 사악한 쌍둥이, 병합을 만나보세요
우리 모두는 여러 브랜치를 하나의 합리적인 솔루션으로 통합하기 위한 힘든 노력을 견뎌 왔습니다. 이전에 Subversion과 같은 중앙 집중식 버전 제어 시스템을 사용할 때는 병합이 아주 까다로운 작업이었습니다. 그러나 Git 및 Mercurial과 같은 최신 버전 제어 시스템은 다른 브랜치에 있는 파일 버전을 추적하는 데 다른 접근 방식을 취합니다.
브랜치는 수명이 짧은 경향이 있기 때문에 코드 베이스 전반에서 병합하기 쉽고 유연합니다. 지속적 통합(CI) 덕분에 브랜치를 자동으로 자주 병합할 수 있고 수명이 짧은 브랜치에는 변경 사항이 덜 포함되므로, Git 및 Mercurial을 사용하는 팀이라면 "병합의 지옥"이란 과거의 일입니다.
작업 브랜치가 아주 훌륭한 이유는 바로 이것입니다.
검증을 거듭하세요
버전 제어 시스템은 병합 결과에 줄 수 있는 영향이 제한적입니다. 자동화된 테스트와 지속적 통합 또한 매우 중요합니다. 대부분의 CI 서버는 새 브랜치를 자동으로 테스트할 수 있으므로, 최종 병합 업스트림에서 발생할 수 있는 "예상치 못한 경우"의 수를 크게 줄이고 메인 코드 라인을 안정적으로 유지하도록 지원합니다.
