Git 브랜치 전략 — GitFlow vs Trunk-based

이 토픽을 마치면

GitFlow와 Trunk-based Development의 차이를 설명할 수 있고, 프로젝트에 맞는 전략을 고를 수 있게 됩니다.

개발자가 5명이면 벌어지는 일

혼자 개발할 때는 main 브랜치 하나로 충분합니다. 근데 5명이 같은 코드베이스에서 동시에 작업하면 문제가 생깁니다.

A가 로그인 기능을 만들고 있는데, B가 같은 파일을 수정해서 push합니다. C는 어제 버그를 고쳤는데 A의 코드와 충돌합니다. D가 출시 준비를 하고 있는데 E가 실험적인 코드를 main에 밀어넣었습니다.

교통 법규 없이 도로에 차를 풀어놓은 것과 같습니다. 차선을 만들어야 합니다.

전략 1: Git Flow — 5개 차선

Git Flow는 브랜치를 다섯 종류로 나눕니다:

text

main ─────────────────────────────────── (출시된 안정 버전)
  │
  └── develop ────────────────────────── (다음 버전 개발 통합)
        │       │       │
        └── feature/login  (로그인 기능)
        └── feature/search (검색 기능)
        │
        └── release/1.2 ─────────────── (출시 전 QA)
  │
  └── hotfix/urgent-bug ─────────────── (긴급 버그 수정)

main — 지금 사용자에게 서비스되고 있는 코드. 여기에 직접 push하는 사람은 없습니다.

develop — 다음 버전을 만들고 있는 곳. 개발자들이 기능을 완성하면 여기에 합칩니다.

feature/ — 기능 하나당 브랜치 하나. feature/login, feature/search 이런 식. 다 만들면 develop에 머지합니다.

release/ — 출시 직전 QA용. 여기서 테스트하고 버그 잡고, 다 되면 main으로 갑니다.

hotfix/ — 이미 출시된 코드에서 긴급 버그가 터졌을 때. main에서 바로 분기해서 고치고 다시 main + develop 양쪽에 합칩니다.

장점은 코드가 안정적이라는 겁니다. 실험적인 코드가 사용자한테 갈 일이 없습니다.

전략 2: Trunk-based — 차선 하나, 빠르게

Trunk-based Development는 반대입니다. main(trunk) 하나만 쓰고, 기능이나 버그 수정이 필요하면 짧은 브랜치를 만들어서 빠르게 머지합니다.

text

main ─── * ─── * ─── * ─── * ─── * ─── (계속 배포)
          ↑     ↑     ↑
        짧은 브랜치들 (1-2일 이내 머지)

브랜치가 오래 살아있으면 안 됩니다. 하루 이틀 안에 머지합니다. 대신 자동화된 테스트가 필수입니다. 테스트를 통과한 코드만 main에 합쳐지고, 합쳐지면 바로 배포됩니다.

구글, 페이스북 같은 대규모 서비스가 이 방식을 씁니다. 하루에도 수십 번 배포합니다.

어떤 걸 골라야 하나

상황	추천
출시 주기가 2주~1달 단위	Git Flow
하루에도 여러 번 배포 (CI/CD)	Trunk-based
QA 팀이 있고 수동 테스트 진행	Git Flow
자동화 테스트가 잘 갖춰져 있음	Trunk-based
모바일 앱 (스토어 심사 필요)	Git Flow
웹 서비스 (즉시 배포 가능)	Trunk-based

정답은 없습니다. 중요한 건 팀 전체가 같은 규칙을 따르는 것이고, 왜 이 전략을 선택했는지 근거를 말할 수 있어야 합니다. "남들이 하니까"는 근거가 아닙니다.

실무에서는 Git Flow를 기반으로 하되 release 브랜치를 생략한다든지, 상황에 맞게 변형하는 경우가 많습니다.

한 가지 확실한 건, 전략 없이 main에 직접 push하는 팀은 결국 "어제 되던 기능이 왜 안 되지?"를 반복하게 됩니다. 브랜치 전략은 코드 충돌 방지가 아니라 팀의 신뢰 유지를 위한 겁니다.

브랜치 이름 짓는 관례

어떤 전략을 쓰든, 브랜치 이름에는 보통 이런 규칙을 씁니다:

text

feature/login          — 새 기능
fix/cart-total-bug     — 버그 수정
hotfix/payment-crash   — 긴급 수정
refactor/auth-cleanup  — 리팩토링

슬래시(/) 앞은 종류, 뒤는 무엇을 하는지입니다. 팀원이 브랜치 목록만 봐도 "아, 이 사람 지금 로그인 기능 만들고 있구나"를 알 수 있어야 합니다.

핵심

Git Flow는 안정성 중심 — 5개 브랜치로 코드를 단계별로 걸러냅니다. Trunk-based는 속도 중심 — main 하나에 빠르게 합치되, 자동 테스트로 품질을 담보합니다. 전략을 고를 때 "배포 주기"와 "테스트 자동화 수준"을 먼저 보세요.