Git 브랜치 전략 완벽 가이드: Git Flow부터 GitHub Flow까지
- Development
- Exien
- · 수정
팀에 Git 브랜치 전략이 왜 필요한가요?
팀 전체가 따르는 브랜치 전략이 있어야 여러 개발자가 함께 쓰는 리포지토리가 혼돈에 빠지지 않습니다. 가장 널리 쓰이는 전략은 정기 릴리즈에 맞는 Git Flow, 지속적 배포에 맞는 GitHub Flow, 그 중간인 GitLab Flow이며, 어떤 것이 맞는지는 팀과 배포 방식에 달려 있습니다.
여러 개발자가 동시에 코드를 작성하다 보면 충돌과 혼란이 생기기 마련입니다. "누가 언제 이 코드를 수정했지?", "배포 나갈 안정적인 버전은 어디에 있지?" 이런 문제를 해결하는 필수 도구가 바로 Git(깃)입니다.
Git의 강력한 기능 중 하나는 '브랜치(Branch)'입니다. 메인 코드 라인에서 독립적으로 가지를 뻗어 안전하게 새 기능을 개발하거나 버그를 수정할 수 있게 해줍니다. 하지만 개발자들이 각자 마음대로 브랜치를 만들고 병합(Merge)하면 리포지토리는 곧 거대한 혼돈에 빠집니다.
그래서 팀 전체가 동의하고 따르는 명확한 '브랜치 전략(Branching Strategy)'이 필요합니다. 아래에서 실무에서 널리 쓰이는 세 가지 대표 전략과, 팀 상황에 맞는 전략을 고르는 방법을 정리합니다.
1. Git Flow(깃 플로우)란 무엇인가요?
Git Flow는 Vincent Driessen이 2010년에 제안한 가장 고전적이고 체계적인 브랜치 모델입니다. 명확하고 엄격한 규칙 덕분에 정기 릴리즈(Release) 주기를 가진 프로젝트나 대규모 엔터프라이즈 환경에 적합합니다.
Git Flow는 항상 유지되는 메인 브랜치 2개와, 필요할 때 만들었다가 작업이 끝나면 삭제하는 보조 브랜치 3가지로 구성됩니다.
메인 브랜치
- main (또는 master): 사용자에게 언제든지 배포할 수 있는 가장 안정적인 프로덕션 레벨의 브랜치입니다. 모든 커밋은 버전 태그를 가지고 있어야 합니다.
- develop: 다음 출시 버전을 위해 개발 중인 최신 코드가 모이는 브랜치입니다. 모든 기능 개발은 이 브랜치를 중심으로 이루어집니다.
보조 브랜치
- feature: 새로운 기능(Feature)을 개발할 때
develop브랜치에서 분기하여 사용합니다. 개발이 완료되면 다시develop브랜치로 병합(Merge)하고 브랜치를 삭제합니다. (예:feature/login) - release: 새로운 버전을 배포하기 위한 준비 브랜치입니다.
develop브랜치에 배포할 기능들이 모이면release브랜치를 분기하여 최종 버그 수정, 메타데이터 업데이트 등의 마무리 작업을 수행합니다. 완료되면main과develop브랜치 양쪽에 병합하고 태그를 생성합니다. - hotfix: 배포된 프로덕션 버전(
main)에서 긴급하게 해결해야 할 심각한 버그가 발생했을 때 사용합니다.main에서 직접 분기하여 버그를 수정한 후,main과develop에 모두 병합합니다.
장점: 규칙이 매우 체계적이어서 복잡한 대규모 릴리즈 과정의 혼란을 최소화할 수 있습니다. 버저닝 관리가 명확합니다. 단점: 브랜치 단계가 많아 흐름이 다소 복잡하고 번거롭습니다. 지속적 배포(CI/CD)나 애자일 환경처럼 하루에도 여러 번 배포하는 모던 웹 서비스에는 무겁게 느껴질 수 있습니다.
2. GitHub Flow(깃허브 플로우)란 무엇인가요?
GitHub Flow는 복잡한 Git Flow의 단점을 보완하려고 GitHub이 고안한 매우 단순하고 가벼운 브랜치 모델입니다. 지속적 배포(Continuous Deployment)가 자동화된 환경이나, 애자일 방법론을 따르는 소규모 웹 애플리케이션 프로젝트에 잘 맞습니다.
GitHub Flow의 핵심은 **"main 브랜치는 언제나 즉시 배포 가능한 상태를 유지해야 한다"**는 단 하나의 원칙입니다.
작업 흐름
- 브랜치 생성: 새로운 기능이나 버그 수정이 필요하면
main브랜치에서 직관적인 이름의 새로운 브랜치를 생성합니다. (예:add-payment-gateway) - 커밋 추가: 자신의 브랜치에서 로컬 작업을 진행하며 커밋을 남기고, 원격 리포지토리(GitHub)에도 수시로 푸시(Push)합니다.
- Pull Request (PR) 오픈: 작업이 어느 정도 완료되었거나, 팀원들의 피드백이나 도움이 필요할 때 Pull Request를 엽니다.
- 리뷰 및 논의: 팀원들과 함께 코드 리뷰를 진행하고, 테스트 코드가 통과되는지 확인합니다.
- 병합 및 배포 (Merge & Deploy): 리뷰가 완료되고 안전하다고 판단되면, PR을
main브랜치로 병합(Merge)합니다.main에 병합된 코드는 즉시(혹은 자동화 파이프라인을 통해) 프로덕션 환경에 배포됩니다.
장점: 워크플로우가 단순해 누구나 쉽게 이해하고 적용할 수 있습니다. CI/CD 환경과 잘 맞고 빠른 템포의 개발에 최적화되어 있습니다.
단점: main 브랜치가 유일한 기준이므로, 코드 리뷰와 자동화된 테스트 환경(CI)이 갖춰져 있지 않으면 치명적인 버그가 프로덕션에 쉽게 노출될 위험이 있습니다.
3. GitLab Flow(깃랩 플로우)란 무엇인가요?
GitLab Flow는 Git Flow의 지나친 복잡함과, 너무 단순해서 배포 환경을 여러 단계(Staging, Pre-production 등)로 관리하기 힘든 GitHub Flow의 단점을 절충한 전략입니다.
GitHub Flow처럼 main 브랜치를 기반으로 Feature 브랜치를 통해 개발하지만, 배포 단계(Environment)에 대응하는 브랜치를 따로 두는 것이 특징입니다.
예를 들어 main 브랜치 외에 pre-production 브랜치, production 브랜치를 둘 수 있습니다. 커밋은 한 방향(Downstream)으로만 흐릅니다.
main (개발/테스트) -> pre-production (스테이징/QA) -> production (실제 배포)
이 방식은 배포 주기를 관리해야 하지만 Git Flow만큼 복잡한 구조는 원하지 않는 팀, 또는 모바일 앱 개발처럼 즉시 배포가 불가능하고 스토어 심사 같은 절차가 있는 환경에 유용합니다.
우리 팀에는 어떤 브랜치 전략이 맞을까요?
정답은 없습니다. 팀 구성, 프로젝트 성격, 배포 파이프라인의 구축 수준에 따라 골라야 합니다.
| 상황 | 전략 |
|---|---|
| 명확한 버전 관리와 정기 릴리즈가 필요한 솔루션, 앱 패키지 | Git Flow |
| 매일 수시로 배포가 이루어지는 웹 서비스, 애자일 팀 | GitHub Flow |
| 여러 배포 환경(Dev, Stg, Prod) 관리가 필요하면서도 단순한 흐름을 원할 때 | GitLab Flow |
어떤 전략을 선택하든 가장 중요한 것은 팀원 모두가 그 규칙을 명확히 이해하고 철저히 준수하는 것, 그리고 코드 리뷰 문화를 정착시키는 것입니다.
