Git Flow: 정의, 브랜칭 모델 및 프로젝트에서의 활용

Git Flow란 무엇인가?

Git Flow는 개발, 리리스 및 수정을 관리하기 위한 브랜치 및 머지 규칙의 엄격한 구조를 정의하는 Git 브랜칭 모델입니다. Vincent Driessen은 2010년 1월에 “A successful Git branching model”을 게재하였고, 그 이후 Git Flow는 기업 Java 및 .NET 개발의 사실상 표준이 되었습니다. 주요 아이디어는 코드를 다양한 안정성 레벨을 가진 다섯 가지 브랜치 유형으로 분리하는 것입니다.

Atlassian Git Tutorials, 2024에 따르면, Git Flow는 두 개의 영구 브랜치(main, 이전 master, 그리고 develop)에 기반합니다. 다른 모든 브랜치는 일시적입니다: feature, release, hotfix. 각 브랜치 유형에는 명확히 정의된 라이프사이클과 머지 규칙이 있습니다. 모바일 개발에서 Git Flow는 정규적인 리리스 사이클(2–4주) 및 여러 버전 지원이 있는 프로젝트에서 사용됩니다.

Git Flow는 통합을 위한 별도의 develop 브랜치가 필요하다는 점에서 간단한 모델(GitHub Flow)과 다릅니다. 이로인해 머지 프로세스에 한 단계가 추가되지만, 미완료된 기능을 리리스 준비된 코드로부터 격리할 수 있습니다.

Vincent Driessen과 Git Flow의 역사

2010년, Vincent Driessen은 “A successful Git branching model”을 게재하였고, 이는 Git 역사에서 가장 많이 인용된 글 중 하나가 되었습니다. 이 모델은 고정된 리리스와 병렬 버전 지원이 있는 프로젝트를 위해 만들어졌습니다. 2020년, Driessen은 Git Flow가 현대 CI/CD 실무에 덜어졌다고 인정했지만, 이 모델은 긴 리리스 사이클과 고구 버전 지원이 필요한 프로젝트에 여전히 의미가 있습니다.

# Git Flow 초기화
git flow init

# feature 브랜치 생성
git flow feature start "add-auth"

# feature 브랜치 완료(develop으로 머지)
git flow feature finish "add-auth"

# release 생성
git flow release start "1.2.0"
git flow release finish "1.2.0"

Main 브랜치: 리리스 코드 및 태깅

Main(이전 master)은 배포 준비가 된 리리스 코드만을 포함하는 기본 브랜치입니다. main의 각 커밋은 세망틱 버전옹 형식으로 태깅된 특정 제품 버전에 해당해야 합니다(예: v1.0.0, v1.1.0). main에서는 직접 개발이 이루어지지 않습니다 — 변경사항은 release 또는 hotfix 브랜치를 통해서만 이러한 곳에 도달합니다.

semver.org, 2024에 따르면, main의 태그는 MAJOR.MINOR.PATCH 형식을 사용합니다. MAJOR는 호환성이 없는 API 변경에 대해 증가하고, MINOR는 효율성을 유지하며 기능을 추가하는 경우, PATCH는 버그 수정에 대해 증가합니다. Git Flow에서는 각 리리스 완료 시 버전 태그가 있는 커밋이 자동으로 main에 생성됩니다.

Main 브랜치는 프로덕션에 배포되는 유일한 브랜치입니다. 모바일 프로젝트의 경우, main으로 푸시하면 App Bundle 또는 IPA 빌드 파이프라인과 Google Play / App Store 게재가 시작됩니다. GitLab CI/CD 설정에서 main은 force-push 및 삭제로부터 보호됩니다.

세망틱 버전옹 및 태그

main의 각 커밋에는 SemVer 형식(vMAJOR.MINOR.PATCH)의 태그가 함께 됩니다. MAJOR — 호환성이 없는 API 변경, MINOR — 효율성을 유지하는 새 기능, PATCH — 버그 수정. 예: v2.1.0은 버그 수정 없이 새 기능이 추가된 두 번째 메이저 리리스를 의미합니다. Git Flow에서는 git flow release finish 명령어로 release 또는 hotfix를 완료할 때 태그가 자동으로 생성됩니다.

Develop 브랜치: 개발의 통합 라인

Develop은 Git Flow에서 두 번째 영구 브랜치로, 완료된 모든 기능을 통합하도록 설계되었습니다. 개발자는 코드 리뷰 및 CI/CD 검사를 통과한 후 feature 브랜치를 develop에 머지합니다. Develop에는 현재 스프린트의 모든 구현된 기능을 포함한 최신 안정 코드가 포함됩니다.

DataSift Git Flow Guide, 2024에 따르면, develop은 진행 중인 통합으로 일시적으로 불안정할 수 있습니다. 문제를 막기 위해 팀은 지속적 통합(CI)을 실천합니다: 각 기능은 develop에 머지되기 전에 완전한 테스트 스위트를 통과해야 합니다. CI가 실패하면 개발자는 다음 머지 전에 코드를 수정합니다. Develop은 항상 현재 main 버전과 연결되어 있으며, 리리스 직후 머지를 통해 develop이 main과 동기화됩니다.

Feature 브랜치: 새로운 기능 개발

Feature 브랜치는 개별 기능, 버그 수정 또는 실험를 위한 임시 브랜치입니다. 각 feature 브랜치는 develop에서 생성되고 완료 후 develop으로 다시 머지됩니다. feature 브랜치의 이름은 일반적으로 태스크 번호나 간략한 설명을 포함합니다: feature/APP-123-add-oauth, feature/redesign-profile. Git Flow에서 feature 브랜치는 무제한으로 존재할 수 있습니다.

Pro Git Book, 2024에 따르면, feature 브랜치는 격리된 개발 환경입니다: 한 브랜치의 변경사항은 머지될 때까지 다른 브랜치에 영향을 미치지 않습니다. 모바일 프로젝트에서 feature 브랜치는 완료 시 큰 고작을 피하기 위해 rebase 또는 merge를 통해 develop과 동기화됩니다. MR을 생성하기 전에 feature 브랜치를 develop에 rebase할 것이 권장됩니다.

# 수동 feature 브랜치 생성(git flow 없이)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# CLI를 통한 GitLab에서 MR 생성
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Release 브랜치: 리리스 준비

Release 브랜치는 리리스를 준비하기 위해 develop에서 생성되는 임시 브랜치입니다. develop에 새 버전에 맡은 기능이 충분히 있으면, 팀은 release/X.Y.Z 브랜치를 생성합니다(예: release/2.1.0). 이 브랜치에서는 버전 증가, 로컬라이제이션 업데이트, 최종 테스트, 치명적인 버그 수정 같은 최종 변경만 이루어집니다.

Atlassian Git Tutorials, 2024에 따르면, release 브랜치는 핵심 문제를 해결합니다: 최종 변경사항을 병렬 개발로부터 격리하는 것입니다. 리리스가 준비되는 동안에도 다음 리리스를 위한 새 기능이 develop에 계속 머지됩니다. 완료 후 release 브랜치는 main(태그와 함께)과 develop(버전 증가를 동기화하기 위해)에 머지됩니다.

Hotfix 브랜치: 프로덕션의 긴급 수정

Hotfix 브랜치는 프로덕션의 치명적 버그를 긴급 수정하기 위한 임시 브랜치입니다. Git Flow에서 develop 대신 main에서 생성되는 유일한 브랜치 유형입니다. 이름 형식: hotfix/X.Y.Z+1(예: hotfix/2.1.1). 완료 후 hotfix 브랜치는 동시에 main(새 패치 리리스로)과 develop(미래 리리스에서 수정이 잃하지 않도록)에 머지됩니다.

DataSift Git Flow Guide, 2024에 따르면, hotfix 브랜치는 가능한 깨단 있어야 합니다 — 수정과 테스트만 포함합니다. hotfix에는 새 기능이나 리팩토링이 포함되어서는 안 됩니다. 모바일 개발에서 hotfix는 치명적 크래시(crash rate > 0.1%), 보안 취약점 또는 App Store의 차단 버그 수정에 사용됩니다.

모바일 개발을 위한 Git Flow의 장점과 단점

Git Flow는 큰 팀과 정규적인 리리스가 있는 프로젝트에 특히 유용한 명확한 구조를 제공합니다. 장점: feature 브랜치에서 미완료 기능의 격리, 개발을 차단하지 않고 리리스를 준비할 수 있는 능력, hotfix를 통한 여러 버전 지원. 단점: 초보자에게 복잡함, 정규적인 feature 브랜치 rebase 필요성, 장기 브랜치에서 고작 발생.

Martin Fowler, 2024에 따르면, Git Flow의 주요 단점은 장기 feature 브랜치입니다. develop과 동기화 없이 2+ 주 동안 기능을 개발하면 머지 고작이 심각해집니다. 모바일 프로젝트의 경우, 매일 rebase를 통해 feature 브랜치를 develop에 동기화하는 것이 권장됩니다.

Git Flow는 지속적 배포(각 커밋이 main으로 → 프로덕션)가 있는 프로젝트에 권장되지 않습니다. 그런 프로젝트에는 GitHub Flow 또는 Trunk-Based Development가 더 간단하고 빠른 모델을 제공합니다. 하지만 리리스 사이클과 고구 버전 지원이 있는 프로젝트에서는 Git Flow가 여전히 최고의 선택입니다.

Git Flow가 팀에 해로울 때

Git Flow는 세 가지 경우 문제가 됩니다: 5명 미만의 팀(불필요한 복잡성), 지속적 배포(납품 지연), rebase 규율 부재(장기 feature 브랜치가 머지 고작 유발). 팀이 브랜치 머지와 고작 해결에 20% 이상의 시간을 소비하는 경우 — Git Flow는 그 팀에 적합하지 않으며, 팀이 아무리 커도 마찬가입니다.

Git Flow 대안: GitHub Flow 및 Trunk-Based Development

Git Flow 대안은 CI/CD를 실천하는 팀에 간단한 프로세스를 제공합니다. GitHub Flow는 하나의 영구 브랜치(main)와 feature 브랜치만 사용합니다. 각 기능은 main에서 생성되고, 리뷰 및 CI 후 main으로 머지되어 즐각 배포됩니다. GitHub Flow는 간단하지만 미완료 기능의 격리나 병렬 리리스 준비를 지원하지 않습니다.

GitHub Docs, 2024에 따르면, Trunk-Based Development (TBD)는 더 나갑니다: 모든 개발자가 하나의 브랜치(trunk)에서 작업하고, 1–2일의 브랜치 feature를 사용합니다. Feature toggles는 미완료 코드의 가시성을 제어합니다. TBD에는 높은 CI/CD 규율과 테스트 자동화가 필요합니다.

• GitHub Flow — 한 main + feature 브랜치, CI/CD와 작은 팀에 이상적
• GitLab Flow — Git Flow를 환경 브랜치(statging, production)로 확장
• Trunk-Based Development — 한 브랜치 + feature toggles, 최대 CI/CD, 최소 머지
• One Flow — develop 브랜치 없이 간단화된 Git Flow, main + feature + release만