chp

99점이 100점이 되기 위해 일을 더하는 개발자

2 분 소요

개요

브랜칭 모델은 팀이 Git 저장소에서 브랜치를 생성·병합·삭제하는 방식을 정의하는 워크플로 전략이다. 팀 규모, 배포 주기, 릴리스 방식에 따라 적합한 모델이 다르다.

모델 복잡도 배포 주기 적합 규모
Git flow 높음 버전 기반 정기 릴리스 중대형
Github flow 낮음 지속적 배포(CD) 소중형
Gitlab flow 중간 환경별 단계 배포 중형
Trunk-based 낮음 지속적 통합·배포(CI/CD) 전 규모


Git flow

  • 다양한 유형의 브랜치를 이용한 모델
  • 각 브랜치에는 특정 목적이 있으며 분기 및 머지 정책에 대한 엄격한 규칙을 적용
  • 아키텍쳐

주요 브랜치 (수명 무한)

브랜치 역할 비고
main (master) 항상 프로덕션 준비 상태 반영. 커밋마다 새 릴리스로 정의 가능 자동 빌드·롤아웃 연동 가능
develop 다음 릴리스용 최신 개발 변경 사항 통합 브랜치 (integration branch) 자동 야간 빌드 대상. 안정화 후 main에 머지·태깅

서포트 브랜치 (수명 유한)

브랜치 분기 원본 머지 대상 명명 규칙 목적
Feature develop develop main, develop, release-*, hotfix-* 제외 모두 가능 새 기능 개발. 개발자 로컬에만 존재. --no-ff 권장
Release develop main + develop release-* 릴리스 준비 (버전 번호·메타 데이터, 버그 수정만 허용). 머지 후 태깅
Hotfix main main + develop hotfix-* 프로덕션 긴급 버그 수정. Release 브랜치 존재 시 Release에 머지 후 릴리스 가능
  • Feature 머지 시 --no-ff 사용 권장
  • Hotfix 아키텍처

장단점

  내용
장점 버전이 명시적으로 지정된 소프트웨어, 여러 버전 동시 지원에 적합
단점 절차가 복잡해 빠른 배포 주기에서는 생산성 저하 가능


Github flow

절차

단계 설명
1. 브랜치 생성 main을 기반으로 목적을 명확히 나타내는 이름으로 생성
2. 작업 및 푸시 수정 사항을 커밋·원격 저장소에 반복 푸시. 공동 작업자 기여 가능
3. Pull Request 생성 main으로 PR 생성하여 팀에 리뷰 요청
4. 리뷰 리뷰어가 질문·의견·제안 작성. 수정·커밋·푸시 반복 시 PR 자동 업데이트
5. 머지 PR 승인 후 main에 머지
6. 브랜치 삭제 작업 완료 의미. 실수 방지. PR·커밋 기록은 보존

장단점

  내용
장점 단순하고 자연스러운 코드 리뷰 흐름
단점 배포 환경 분리·릴리스 관리·통합 전략이 명시되지 않음. 규모가 커지면 관리 어려움


Gitlab flow

  • Github flow(단순함)와 Git flow(복잡함) 사이의 균형을 제공하는 모델
  • 배포 환경·릴리스 관리에 대한 추가 지침 포함

브랜치 구조

브랜치 Git flow 대응 역할
feature Feature 브랜치 main 기반으로 생성. 완료 후 main으로 MR(Merge Request) 생성
main (default) develop 브랜치 개발 통합. 테스트 후 production 또는 pre-production으로 MR 생성
pre-production - production 머지 전 추가 검증 단계 (선택적)
production main(master) 브랜치 실제 배포 브랜치. 머지·릴리스·태깅 오버헤드 최소화

장단점

  내용
장점 환경별 브랜치 전략으로 배포 파이프라인과 자연스럽게 연동. Git flow보다 단순
단점 환경 수에 따라 브랜치 수가 늘어날 수 있음


Trunk-based development

  • 하나의 브랜치(trunk 또는 main)만 메인 통합 브랜치로 사용하는 방식
  • 다른 브랜치는 임시로만 사용하며 수명이 매우 짧아야 함 (코드 리뷰, 테스트, 릴리스 목적)
  • 아키텍처
    • 소규모: 직접 trunk에 커밋
    • 대규모: 단기 feature 브랜치 사용

전제 조건

항목 설명
CI (Continuous Integration) 모든 커밋에 대해 자동 빌드·테스트 수행
CD (Continuous Delivery) 검증된 코드를 자동으로 배포 가능 상태 유지
코드 리뷰 페어 프로그래밍 또는 PR 리뷰를 높은 우선순위로 처리
Feature Flags 미완성 기능을 trunk에 포함하면서 비활성화 유지
탄탄한 테스트 커버리지 빠른 통합 주기를 뒷받침하는 자동화 테스트 필수

장단점

  내용
장점 빠른 피드백 루프. merge conflict 최소화. CI/CD와 자연스러운 연동
단점 전제 조건(CI/CD, 테스트, Feature Flag)을 갖추지 않으면 도입이 어려움


관련 포스트

참고