Git-flow
Git-flow는 Vincent Driessen이 그의 블로그에 2010년에 올린 A successful Git branching model 이라는 글이 인기를 끌며 대중적으로 사용되게된 브랜치 전략입니다.
Git-flow에서 사용하는 브랜치의 종류는 5가지이며 크게 항상 유지되는 메인 브렌치(Master, Develop)와 일정 기간 유지되는 보조 브랜치(feature, release, hostfix)로 나뉩니다.
Git-flow 브랜치 구조
- Master : 제품으로 출시될 수 있는 브랜치
- Develop : 다음 출시 버전을 개발하는 브랜치
- Feature : 기능을 개발하는 브랜치
- Release : 다음 버전 출시를 준비하는 브랜치
- Hostfix : 출시 버전에서 발생한 버그를 수정하는 브랜치
1. Master 브랜치
- master 브랜치는 항상 배포 가능한 안정된 코드만을 가지고 있는 메인 브랜치입니다.
- 이 브랜치에서는 직접 코드를 작성하지 않고, 다른 브랜치에서 테스트된 안정된 코드만을 머지합니다.
- 배포 준비가 완료되면 master에서 태그를 생성하여 버전을 관리합니다.
2. Develop 브랜치
- develop 브랜치는 다음 버전을 위한 통합 브랜치입니다.
- 개발 중인 기능들이 통합되고 테스트되는 곳으로, 이 브랜치에서 직접 코드를 작성하게 됩니다.
3. Feature 브랜치
- 새로운 기능을 개발할 때 사용하는 브랜치입니다.
- develop 브랜치에서부터 시작하고, 개발이 완료되면 다시 develop으로 머지합니다.
- 머지할때 주의점은 Fast-Forward로 머지하지 않고, Merge Commit을 생성하며 머지를 해주어야 합니다.
- 이렇게해야 히스토리가 특정 기능 단위로 묶이게 됩니다.
- 네이밍은 feature/branch-name 과 같은 형태로 생성합니다.
4. Release 브랜치
- 새로운 기능 추가 및 버그 수정이 완료된 시점에서 develop 브랜치에서 release 브랜치를 생성합니다.
- release 브랜치에서는 마지막 테스트와 문서 작업 등을 수행하며, 문제가 없으면 master와 develop에 머지하고, 새로운 버전을 태그합니다.
- 네이밍은 release/v1.1 과 같은 형태로 생성합니다.
5. Hotfix 브랜치
- 프로덕션 환경에서 발생한 버그를 수정하기 위한 브랜치입니다.
- master 브랜치에서 생성하고, 버그가 수정되면 master와 develop 브랜치에 머지합니다.
- 네이밍은 hotfix/v1.0.1 과 같은 형태로 생성합니다.
Git-flow 장단점
1. 장점
- 브랜치별로 책임을 명확히 하는 규칙성
- 매우 디테일하게 버전 정보 제공
- master에 있는 코드는 매우 깔끔한 상태 유지(테스트되고 최종 수정된 것만 반영되기 때문)
- 브랜치별로 역할이 있으므로 문제가 있더라도 문제 발생시 각 브랜치를 대기 시킬 필요가 없음
2. 단점
- 많은 브랜치 때문에 생기는 복잡한 규칙
- release 로 인한 많은 동기화 작업
- 애자일의 반복적인 접근법과 Git-Flow의 엄격하고 구체적인 규칙과 충돌
[참고]
