브랜치 전략이란?
개발자가 협업시 소스 코드를 효과적으로 관리하기 위한 work-flow이다.
브랜치의 유연한 구조를 활용해서 다양한 방식으로 소스를 관리하는 역할을 한다.
그 중 가장 널리 사용되는 Git-Flow 전략에 대해 알아보자.
Git-Flow 전략
깃 플로우에는 5가지 브랜치가 존재한다.
- master : 기준이 되는 브랜치로 제품을 배포하는 브랜치
- develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합친다(Merge).
- feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합친다.
- release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA를 하기위 한 브랜치이다.
- hotfix : master 브랜치로 배포시 버그가 발생했을 때 긴급 수정하느 브랜치
feature > develop > release > hotfix > master
왼쪽으로 갈수록 포괄적인 가지이며 마스터 브랜치를 병합할 경우 왼쪽에 있는 모든 가지들의 커밋들도 병합하도록 구성하게 된다.
master와 develop이 가장 중요한 브랜치이고 나머지는 필요에 의해서 운영하는 브랜치로 merge가 되면 사라지게 된다.
Git-Flow 구조 및 흐름
1. 메인 브랜치
master와 develop 두 종류를 말한다.
master 브랜치는 배포 가능한 상태만을 관리하고 develop 브랜치는 다음에 배포할 것을 개발하는 브랜치이다.
dvelop 브랜치는 개발이 완료된 feature 브랜치가 merge되는 통합 브랜치의 역할을 한다.
2. 보조 브랜치
피처 브랜치(feature branch) 또는 토픽 브랜치(topic branch)를 말한다.
보조 브랜치는 새로운 기능을 추가할때 주로 사용 된다.
새로 변경될 개발코드를 분리하고 각각 보존하는 역할을 한다. 기능이 다 완성되면 develop 브랜치로 merge 하고 결과가 좋지 못하면 버리는 방향을 가진다.
3. 릴리즈 브랜치
배포를 위한 최종적인 버그 수정 등의 개발을 수행하는 브랜치를 말한다.
release 브랜치에 있는 코드에 대해 QA를 진행하면서 버그를 고쳐나가고 QA를 통화한 release 브랜치는 배포 준비가 완료된 상태이다.
배고 가능한 상태가 되면 master 브랜치로 병합시키고 출시된 master 브랜치에 버전 태그(ex, v1.0)를 추가한다.
4. 핫픽스 브랜치
배포한 버전에서 긴급하게 수정이 필요할 때 master 브랜치에서 분리하는 브랜치를 말한다.
제폼에서 버그가 발생했을 경우 처리를 위해 해당 브랜치로 정보들을 모아준다.
버그를 잡는 동안에도 다른사람들은 develop 브랜치에서 하던 일을 계속할 수 있다.
hotfix 브랜치에서의 변경사항은 develop 브랜치에도 merge하여 문제가 되는 부분을 처리하고 버그에 대한 수정이 완료된 후에는 develop, master에 곧장 반영하여 tag를 통해 관련 정보를 기록해둔다.
