Git Flow 완벽 가이드: 협업을 위한 브랜치 전략 이해하기
Git Flow란 무엇인가?
Git Flow는 Vincent Driessen이 2010년에 제안한 Git 브랜치 관리 전략입니다. 여러 개발자가 협업할 때 코드 충돌을 최소화하고 안정적인 배포를 가능하게 하는 체계적인 방법론입니다. 특히 정기적인 릴리즈 주기를 가진 프로젝트에서 효과적입니다.
간단히 말하자면, Git Flow는 “어떤 상황에서 어떤 브랜치를 만들고, 어디로 병합해야 하는가?”에 대한 명확한 규칙을 제공합니다.
Git Flow의 핵심 브랜치 구조
Git Flow는 크게 5가지 종류의 브랜치로 구성됩니다.
1. Main (Master) 브랜치
프로덕션 환경에 배포되는 코드만 존재하는 브랜치입니다. 이 브랜치의 모든 커밋은 실제 서비스에 반영된 버전을 의미하며, 각 커밋에는 버전 태그(v1.0.0, v1.1.0 등)가 붙습니다.
절대로 직접 커밋하지 않으며, 오직 release 브랜치나 hotfix 브랜치에서만 병합됩니다. Main 브랜치는 항상 배포 가능한 안정적인 상태를 유지해야 합니다.
2. Develop 브랜치
다음 릴리즈를 위한 개발이 진행되는 메인 브랜치입니다. 개발자들이 완료한 기능들이 모이는 통합 브랜치 역할을 합니다.
Main 브랜치에서 최초 분기되어 생성되며, 프로젝트가 종료될 때까지 유지됩니다. 새로운 기능 개발은 항상 develop 브랜치를 기준으로 시작됩니다.
3. Feature 브랜치
새로운 기능을 개발할 때 사용하는 브랜치입니다. develop 브랜치에서 분기되며, 기능 개발이 완료되면 다시 develop으로 병합됩니다.
브랜치 이름은 보통 feature/기능명 형식을 사용합니다. 예를 들어 “feature/user-login”, “feature/payment-module” 같은 식입니다. 여러 개발자가 동시에 다른 feature 브랜치에서 작업할 수 있어 협업이 원활합니다.
4. Release 브랜치
배포를 준비하는 브랜치입니다. develop 브랜치에서 분기되며, 버전 번호 수정, 마지막 버그 수정, 문서 작업 등 배포 직전 작업을 수행합니다.
릴리즈 준비가 완료되면 main과 develop 양쪽 모두에 병합됩니다. Main에 병합할 때는 버전 태그를 함께 생성합니다. 브랜치 이름은 release/버전명 형식을 사용합니다.
5. Hotfix 브랜치
프로덕션 환경에서 긴급하게 수정해야 할 버그가 발견되었을 때 사용하는 브랜치입니다. Main 브랜치에서 직접 분기되며, 수정 완료 후 main과 develop 양쪽에 모두 병합됩니다.
긴급 패치이므로 다음 릴리즈를 기다릴 수 없는 상황에서 사용됩니다. 브랜치 이름은 hotfix/버전명 형식을 사용합니다.
Git Flow 작업 흐름 다이어그램
Main ──●────────────────●──────────────●────
│ ↑ ↑
│ (release) (hotfix)
│ │ │
Develop └─●──●──●──●────●──●──●───────●─────
↑ ↑ ↑ ↑
│ │ │ │
Feature │ │ └───────┘
│ │
Feature │ └─────────────────────────
│
Feature └────────────────────────────
실제 개발 시나리오로 이해하기
쇼핑몰 프로젝트를 예로 들어 Git Flow 흐름을 살펴보겠습니다.
시나리오 1: 새로운 기능 개발
장바구니 기능을 개발한다고 가정해봅시다.
# develop 브랜치에서 시작 git checkout develop git pull origin develop # feature 브랜치 생성 git checkout -b feature/shopping-cart # 개발 작업 후 커밋 git add . git commit -m "장바구니 추가 기능 구현" # develop으로 병합 git checkout develop git merge feature/shopping-cart # feature 브랜치 삭제 git branch -d feature/shopping-cart
이 과정에서 다른 개발자는 feature/payment-gateway 브랜치에서 결제 기능을 동시에 개발할 수 있습니다. 각자 작업이 끝나면 develop 브랜치로 병합하여 통합합니다.
시나리오 2: 배포 준비
충분한 기능이 develop 브랜치에 쌓였다면 릴리즈를 준비합니다.
# release 브랜치 생성 git checkout develop git checkout -b release/1.0.0 # 버전 번호 수정, 문서 업데이트 등 # 마지막 버그 수정 # main 브랜치로 병합 및 태그 생성 git checkout main git merge release/1.0.0 git tag -a v1.0.0 -m "Release version 1.0.0" # develop 브랜치로도 병합 git checkout develop git merge release/1.0.0 # release 브랜치 삭제 git branch -d release/1.0.0
Release 브랜치를 사용하는 동안 develop 브랜치에서는 다음 버전을 위한 개발을 계속 진행할 수 있습니다.
시나리오 3: 긴급 버그 수정
배포 후 결제 모듈에서 치명적인 버그가 발견되었습니다.
# main 브랜치에서 hotfix 브랜치 생성 git checkout main git checkout -b hotfix/1.0.1 # 버그 수정 git add . git commit -m "결제 모듈 버그 긴급 수정" # main 브랜치로 병합 및 태그 git checkout main git merge hotfix/1.0.1 git tag -a v1.0.1 -m "Hotfix version 1.0.1" # develop 브랜치로도 병합 git checkout develop git merge hotfix/1.0.1 # hotfix 브랜치 삭제 git branch -d hotfix/1.0.1
Git Flow의 장단점
장점:
명확한 브랜치 구조로 협업이 체계적입니다. 각 브랜치의 역할이 분명하여 새로운 팀원도 쉽게 이해할 수 있습니다. 여러 버전을 동시에 관리하기 용이하며, 배포 프로세스가 안정적입니다.
단점:
브랜치가 많아 복잡할 수 있습니다. 지속적 배포(Continuous Deployment)가 필요한 프로젝트에서는 과도하게 무거울 수 있습니다. 간단한 프로젝트에서는 오버엔지니어링이 될 수 있습니다.
Git Flow가 적합한 프로젝트
정기적인 릴리즈 주기를 가진 프로젝트, 여러 버전을 동시에 지원해야 하는 제품, 대규모 팀이 협업하는 프로젝트에 적합합니다. 예를 들어 모바일 앱, 패키지 소프트웨어, 엔터프라이즈 솔루션 등이 해당됩니다.
반면 웹 서비스처럼 수시로 배포하는 프로젝트라면 GitHub Flow나 GitLab Flow 같은 더 간단한 전략이 적합할 수 있습니다.
실무 팁
브랜치 이름은 팀 내에서 일관된 규칙을 정하세요. feature/issue-번호-기능명 형식으로 이슈 트래커와 연동하면 편리합니다.
Pull Request를 활용하여 코드 리뷰를 진행하세요. Feature 브랜치를 develop에 바로 병합하지 말고, PR을 통해 팀원들의 검토를 받으면 코드 품질이 향상됩니다.
자동화 도구를 활용하세요. git-flow 확장 도구를 설치하면 브랜치 생성과 병합을 명령어 하나로 처리할 수 있습니다.
Git Flow는 처음에는 복잡해 보이지만, 규칙을 이해하고 몇 번 실습하면 자연스럽게 익숙해집니다. 팀의 워크플로우에 맞게 유연하게 적용하는 것이 중요합니다.
