Git: 주요 브랜치 전략 3가지

현대 소프트웨어 개발에서 널리 사용되는 대표적인 브랜치 전략(Branching strategy)을 이해하면, 팀의 규모나 업무 프로세스, 제품 특성에 따라 적절한 브랜치 모델을 채택하는 데 큰 도움이 됩니다.

주요 브랜치 전략 3가지

전략	대상/특징	브랜치 복잡도	릴리즈/핫픽스 분리	CI/CD 친화
Git Flow	대형 조직, 복잡 릴리즈	높음	O	보통
GitHub Flow	소규모, 빠른 배포	낮음	X	매우높음
Trunk-based Development	스타트업, DevOps 조직	매우 낮음	X (feature flag)	최고

1. Git Flow

복잡한 프로젝트, 릴리즈와 긴 유지보수 주기가 있는 경우에 적합

• 브랜치를 역할별로 엄격히 구분하고, 여러 개발 흐름을 동시에 관리할 수 있게 설계됨.

• main(혹은 master): 출시(Production) 버전만 저장

• develop: 개발의 중심, 모든 기능/버그 수정은 develop으로 머지

• 추가적으로 기능(feature), 출시 준비(release), 긴급 패치(hotfix) 브랜치 운용

브랜치 구조

• main(master): 제품의 "공식 릴리즈" 이력 저장소. HOTFIX 까지만 merge 가능

• develop: 다음 릴리즈를 위한 통합 개발 브랜치

• feature/: 각각의 신규 기능 개발 브랜치 (feature/XXX)

• release/: 배포 준비, QA, 배포 작업을 위한 브랜치

• hotfix/: 긴급 배포를 위한 브랜치

흐름

graph TD
  master -->|branch| hotfix
  master -->|branch| release
  develop -->|branch| feature
  feature -->|merge| develop
  develop -->|merge| release
  release -->|merge| master
  hotfix -->|merge| master
  hotfix -->|merge| develop
  release -->|merge| develop

장점

• 작업 구분이 명확해 대규모 프로젝트, 여러 개발 팀에 적합

• 여러 버전을 동시에 관리 가능(릴리즈/핫픽스 병행)

단점

• 브랜치가 많아짐(복잡성 증가), 작은 팀에는 오버헤드

• 충돌, 동기화 관리가 복잡해질 수 있음

2. GitHub Flow

빠른 배포와 간단한 협업, DevOps/CI/CD 중심 조직에 적합

• 메인 브랜치를 main/master로 단일화, 기능이나 수정은 모두 별도 브랜치에서 작업

• Pull Request(CI, 코드리뷰) → main(master)에 Merge 방식

브랜치 구조

• main(master): 오직 “배포 가능한 상태”의 코드만. 항상 green 상태 보장

• (기능) 브랜치: feature-XXX, fix-XXX 등 자유롭게 생성

  • 이름 규칙은 자유

흐름

1. main에서 브랜치 생성 → 로컬에서 작업/커밋

2. 원격 저장소에 push 후 PR 작성

3. PR에 자동화 테스트/리뷰/승인 → 문제가 없으면 main에 merge

4. Merge 후 main에서 바로 배포

장점

• 심플하고 단순하여 소규모, 빠른 배포 주기 팀에 최적

• 자동화와 리뷰 프로세스에 최적화

단점

• 복잡한 릴리즈, 여러 버전에 대한 유지보수에는 부적합

• 한 번에 여러 릴리즈 버전을 다루기 어려움

3. Trunk-based Development

극단적 단순화, 매우 빠른 배포와 CI/CD가 핵심인 팀에 적합

• 전체 개발자가 메인 브랜치(보통 main/master 또는 trunk)에 직접 합쳐가며(merge) 개발

• 짧은 제한(branch life per PR: 1, 2일 이내)

• 여러 배포 버전을 관리하지 않고, 릴리즈는 태그(tag)로만 관리

• “Feature Flag(특정 기능만 on/off)” 활용이 많음

브랜치 구조

• main(trunk): 모든 개발자가 작업(merge/rebase)하는 브랜치

• (잠깐 쓰는) feature 브랜치: 1~2일 이하 유지, PR로 main에 merge

흐름

1. main에서 branch 따서 빠른 작업(1~2일)

2. main/trunk에 merge or rebase

3. 매우 자주(하루에도 여러 번) main이 최신 deployable 상태가 되도록 관리

4. 롤아웃(pilot→전체), feature flag 활용

장점

• 압도적으로 빠른 배포 및 배포 자동화에 최적화

• 브랜치 오버헤드/복잡성 최소화

단점

• 큰 기능 단위 작업에 부적합(병합 충돌 발생 가능)

• 조직 내 strict한 테스트 자동화, 피드백 체계 필요

• 기능 Flag 설계 노하우 필요

4. 기타 전략

• Release Flow (마이크로소프트): Trunk와 유사하지만, 배포 릴리즈를 별도의 릴리즈 브랜치에서 관리

• GitLab Flow: GitHub Flow + 환경별 배포 혹은 릴리즈 브랜치 조합

• Forking workflow: 오픈소스 협업에서, 포크 → 브랜치 후 PR 방식