아키텍처
브랜치 전략 수립을 위한 전문가의 조언들
두줄요약
Git-flow·GitHub-flow·GitLab-flow를 배포 방식과 운영 조건에 따라 비교했습니다. 정기 배포 웹 환경에는 develop를 제거한 이슈 기반 브랜치 구성을 제안합니다.
구조와 흐름
- Git-flow, GitHub-flow, GitLab-flow의 배포 방식·브랜치 구성·적용 조건 비교
- 정기 배포 웹 애플리케이션용으로 feature·release·hotfix·master를 구성하고 develop 제거
- 이슈 단위 feature 생성, 동일 배포 시점별 release 통합 테스트 후 master 병합
선택 이유
- Git-flow의 버저닝·장기 유지보수 적합성과 GitHub-flow의 상시 배포·단순성 구분
- 다중 프로젝트와 정기 배포 환경에서 develop 중심 흐름의 소스 프리징·배포 순서 제약 완화
- GitLab-flow의 이슈 기반 추적으로 브랜치 생성 목적과 생명 주기 명확화
트레이드오프
- 단일 브랜치 방식의 master 손상 시 전체 업무 중단과 rebase 기반 맥락 추적 어려움
- 과도한 장기 브랜치 계층의 병합 단계 증가와 업무 처리 속도 저하
- 이전 버전 지원 시 버전별 장기 release 브랜치 필요
주의할 점
- master는 언제든 배포 가능한 상태 유지, 충돌 해결은 release에서 처리
- release 배포 시 master 변경 사항을 release에 반영
- 정해진 워크플로우의 관성 대신 프로젝트 배포 주기·버저닝·유지보수 조건 검토
