Git Flow, GitHub Flow, GitLab Flow 비교

깃 플로(Git Flow), 깃허브 플로(GitHub Flow), 깃랩 플로(GitLab Flow)는 팀이 브랜치를 만들고 병합하고 배포하는 방식을 정의한 대표적인 브랜치 전략이다. Git Flow는 버전 릴리스를 전제로 여러 종류의 브랜치를 엄격하게 나누는 전략이고, GitHub Flow는 메인 브랜치 하나와 짧은 기능 브랜치만으로 지속 배포를 지향하는 단순한 전략이며, GitLab Flow는 그 중간에서 환경 브랜치나 릴리스 브랜치로 배포 단계를 표현하는 절충안이다. 어떤 전략이 맞는지는 배포 주기와 제품 형태에 따라 달라진다.

Git Flow: 릴리스 중심의 엄격한 전략

Git Flow는 2010년 빈센트 드리센(Vincent Driessen)이 제안한 모델로, 다섯 종류의 브랜치를 역할별로 나눈다. 영구 브랜치로 main과 develop을 두고, 보조 브랜치로 feature, release, hotfix를 필요할 때 만들었다가 병합 후 삭제한다.

• main: 배포된 버전만 존재하며 커밋마다 버전 태그를 붙인다.
• develop: 다음 릴리스를 준비하는 통합 브랜치다.
• feature: develop에서 분기해서 기능을 개발하고 develop으로 돌아간다.
• release: 릴리스 직전 안정화 작업을 하며, 완료되면 main과 develop 양쪽에 병합한다.
• hotfix: 배포된 버전의 긴급 버그를 main에서 직접 분기해 고치고 양쪽에 병합한다.

# 기능 개발
git checkout -b feature/<기능명> develop
git checkout develop
git merge --no-ff feature/<기능명>

# 릴리스 준비와 배포
git checkout -b release/1.2.0 develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0

버전을 명시적으로 관리해야 하는 설치형 소프트웨어, 모바일 앱, 여러 버전을 동시에 지원해야 하는 제품에 잘 맞는다. 반면 브랜치 구조가 복잡하고 병합 지점이 많아, 하루에도 여러 번 배포하는 웹 서비스에는 과한 전략이라는 비판을 받는다. 제안자 본인도 지속 배포 환경이라면 더 단순한 전략을 쓰라고 후기를 남겼다.

GitHub Flow: 지속 배포를 위한 최소 전략

GitHub Flow는 규칙이 단 하나의 원칙으로 요약된다. main 브랜치는 언제나 배포 가능해야 한다는 것이다. 모든 작업은 main에서 분기한 기능 브랜치에서 진행하고, 풀 리퀘스트(Pull Request)를 열어 리뷰와 자동 테스트를 통과하면 main에 병합한다. 병합된 main은 곧바로, 혹은 매우 짧은 주기로 배포된다.

git switch main
git pull origin main
git switch -c feature/<기능명>
# 작업 후
git push -u origin feature/<기능명>
# PR 생성, 리뷰와 CI 통과 후 main에 병합, 즉시 배포

develop도 release도 없기 때문에 배우기 쉽고 병합 충돌이 줄어든다. 다만 릴리스 버전 개념이 없어서 여러 버전을 병행 지원하거나 배포 시점을 통제해야 하는 환경에는 맞지 않고, 배포 파이프라인과 테스트 자동화가 충분히 갖춰져 있어야 안전하게 굴러간다. 아직 공개하면 안 되는 기능은 기능 플래그(feature flag)로 숨기는 기법을 함께 쓴다.

# main에 먼저 수정 후 릴리스 브랜치로 가져오기
git checkout 2-3-stable
git cherry-pick <수정-커밋-해시>