본 워크플로우는 모든 작업에 대한 Master 와 Develop 2개의 브랜치를 대상으로 Workflow 가 진행된다.
Master 브랜치를 기준으로 2개의 브랜치를 사용하여 변경 이력을 유지하며 오직 Release 이력을 관리하기 위해 사용되어야 한다.
즉, Master 브랜치는 Release 태그를 적용하기에 매우 중요하다.
Develop 브랜치는 기능 개발을 위한 브랜치들을 병합하기 위해 사용한다.
Master 브랜치는 축약된 프로젝트 이력 및 태그만 관리하며, 그 외 Develop 브랜치는 모든 기능 개발 이력을 관리한다.
기능브랜치
새로운 기능은 각각의 브랜치에서 개발하고 백업 및 협업을 위해서 중앙 저장소에 푸시한다.
그런데, master 브랜치에서 기능 개발을 위한 브랜치를 따는 것이 아니라, develop 브랜치에서 딴다.
그리고, 기능 개발이 끝나면 다시 develop 브랜치에 작업 내용을 병합한다.
즉, 기능 개발을 위한 브랜치는 master 브랜치와는 어떤 상호 작용도 하지 않는다.
릴리즈 브랜치
develop 브랜치에 릴리스를 할 수 있는 수준만큼 기능이 모이면(또는 정해진 릴리스 일정이 되면), develop 브랜치를 기준으로 릴리스를 위한 브랜치를 생성한다.
이 브랜치를 만드는 순간부터 릴리스 사이클이 시작되고, 버그 수정, 문서 추가 등 릴리스와 직접적으로 관련된 작업들을 제외하고는 이 브랜치에 새로운 기능을 추가 병합하지 않는다.
릴리스 준비가 완료되면 master 브랜치에 병합하고 버전 태그를 부여한다.
그리고, 릴리스를 준비하는 동안 develop 브랜치가 변경되었을 수 있으므로 develop 브랜치에도 병합한다.
릴리스를 위한 전용 브랜치를 사용함으로써 한 팀이 릴리스를 준비하는 동안 다른 팀은 다음 릴리스를 위한 기능 개발을 계속할 수 있다.
즉, 딱딱 끊어지는 개발 단계를 정의하기에 아주 좋다.
예를 들어, 이번 주에 버전 4.0 릴리스를 목표로한다라고 팀 구성원들과 쉽게 소통하고 합의할 수 있다는 말이다.
릴리스 브랜치는 release-* 또는 release/*처럼 이름 짓는 것이 일반적인 관례다.
릴리스 준비가 끝나면, 릴리스 브랜치를 master와 develop 브랜치에 병합하고, 릴리스 브랜치는 삭제한다.
develop브랜치에도 병합하는 이유는 릴리스를 준비하면서 개발 중인 다른 기능에 영향을 줄 수 있는 작업을 했을 수도 있기 때문이다.
이때 팀 내 코드 리뷰가 필요한 경우, 병합 리퀘스트(풀리퀘스트) 를 요청하여 코드 리뷰 진행 후 병합이 가능하다.
Hotfix 브랜치
운영 환경에 릴리스한 후 발견된 긴급 버그수정은 ‘hotfix’ 브랜치를 사용한다.
hotfix 브랜치만 Master 에서 바로 생성할 수 있다.
긴급 버그수정이 완료되면, Master 와 Develop 브랜치 양쪽으로 병합하고 새로운 버전 이름으로 태그를 적용한다.
버그 수정만을 위한 브랜치를 따로 만들었기때문에, 다음 릴리스를 위해 개발하던 작업 내용에 전혀 영향을 주지 않는다.
‘hotfix’ 브랜치는 master 브랜치를 부모로 하는 임시 브랜치라고 생각하면 된다.