브랜치 전략

브랜치를 만들고 합치는 법을 배웠다면, 이제 팀이 브랜치를 어떻게 운영할지 정할 차례입니다. 브랜치 전략은 "어떤 브랜치를 두고, 언제 만들고, 어디로 합치고, 언제 배포하는가"에 대한 팀의 약속입니다. 정답은 없고, 팀 규모와 배포 주기에 맞는 전략을 고르는 것이 중요합니다.

학습 목표

• 브랜치 전략이 왜 필요한지 이해한다.
• Git Flow, GitHub Flow, GitLab Flow, 트렁크 기반 개발의 차이를 안다.
• 우리 팀에 맞는 전략을 고르는 기준을 세운다.

왜 전략이 필요한가

혼자라면 main 하나로도 충분합니다. 하지만 여러 명이 동시에 기능을 만들고, 배포는 안정적으로 해야 한다면 규칙이 없으면 금방 엉킵니다. 브랜치 전략은 충돌을 줄이고, 배포 가능한 상태를 안전하게 유지하며, 리뷰와 릴리스를 예측 가능하게 만듭니다.

Git Flow

가장 많이 알려진 전략으로, 역할이 정해진 여러 브랜치를 둡니다.

• main — 배포된 안정 버전. 태그로 릴리스를 표시
• develop — 다음 릴리스를 위한 통합 브랜치
• feature/* — 기능 개발. develop에서 따서 develop으로 합침
• release/* — 출시 준비(버전 고정·버그 수정)
• hotfix/* — 운영 중 긴급 수정. main에서 따서 main·develop에 반영

main ──●────────────●─────  (릴리스 태그)
        \          /
develop ─●──●──●──●────────
            \  /
feature/login ●

장점: 릴리스·핫픽스 절차가 명확해 정기 배포·버전 관리에 강합니다. 단점: 브랜치가 많고 절차가 무거워, 자주 배포하는 웹 서비스에는 과합니다.

GitHub Flow

훨씬 단순합니다. main 하나 + 짧은 기능 브랜치가 전부입니다.

1. main에서 기능 브랜치를 딴다.
2. 작업하고 Pull Request를 올린다.
3. 리뷰·CI 통과 후 main에 머지한다.
4. main은 항상 배포 가능하며, 머지되면 바로 배포한다.

장점: 단순하고 빠릅니다. 지속적 배포(CD)와 잘 맞습니다. 단점: 여러 버전을 동시에 유지하거나 릴리스를 따로 관리해야 하는 경우엔 부족합니다.

GitLab Flow

GitHub Flow에 환경/릴리스 브랜치를 더한 절충안입니다. main에 머지한 뒤, staging·production 같은 환경 브랜치로 흘려보내며 배포 단계를 표현합니다.

feature → main → staging(검증) → production(배포)

배포 환경이 여러 단계인 팀이 단순함과 통제력을 함께 가져가려 할 때 적합합니다.

트렁크 기반 개발 (Trunk-Based)

모두가 **하나의 트렁크(main)**에 아주 짧게 사는 브랜치로 자주 합칩니다(하루 안에). 장기 브랜치를 피해 통합 지옥을 막고, 미완성 기능은 **기능 플래그(feature flag)**로 숨깁니다.

장점: 통합이 잦아 충돌이 작고, CI/CD와 가장 잘 맞습니다. 단점: 강한 자동화 테스트와 기능 플래그 문화가 전제되어야 안전합니다.

무엇을 고를까

상황	추천
정기 릴리스·여러 버전 유지	Git Flow
웹 서비스·지속적 배포	GitHub Flow
배포 환경이 단계별로 나뉨	GitLab Flow
강한 CI/CD·빠른 통합	트렁크 기반

대부분의 작은 웹 팀에는 GitHub Flow가 가장 무난한 출발점입니다. 규모가 커지고 릴리스 관리가 복잡해지면 그때 더 무거운 전략을 도입해도 늦지 않습니다.

요약

브랜치 전략은 팀이 브랜치를 운영하는 약속입니다. Git Flow는 절차가 명확하지만 무겁고, GitHub Flow는 단순해 지속적 배포에 강하며, GitLab Flow는 환경 단계를, 트렁크 기반은 잦은 통합을 강조합니다. 팀 규모와 배포 주기에 맞춰 가장 단순한 것부터 시작하세요.