Git-flow 브랜치 전략: 릴리스와 긴급 수정을 분리하는 방법

릴리스 안정성을 위해 브랜치 책임을 나누는 방식

Git-flow는 Vincent Driessen이 2010년 「A successful Git branching model」 블로그 포스트에서 제안한 Git 브랜치 관리 전략이다. 배포 뒤 유지보수가 어렵거나 코드 품질을 엄격하게 관리해야 하는 프로젝트에서 특히 활용하기 좋다.

이 전략의 핵심은 개발 중인 변경과 배포 가능한 코드를 분리하는 데 있다. 견고한 코드베이스를 유지하면서 결함을 줄이고, 문제가 발생했을 때 수정 경로를 분명하게 만들며, 릴리스 준비 과정을 체계적으로 관리한다.

각 브랜치가 맡는 일

Git-flow는 develop, feature, release, master, hotfix 브랜치를 중심으로 운영된다.

develop은 개발의 중심축이다. 모든 개발 작업은 여기에서 시작하며, feature·release·hotfix 브랜치에서 마무리된 변경이 다시 모이는 곳이다.

feature는 신규 기능 개발과 버그 수정을 위한 브랜치다. 여러 개를 동시에 둘 수 있고 feature/기능명 형식을 사용한다. develop에서 분기해 작업한 뒤 develop으로 병합한다.

release는 배포를 준비하는 브랜치다. develop에서 분기하며, 배포 전 최종 점검과 버그 수정만 수행한다. 새로운 기능은 추가하지 않는다. 준비가 끝나면 master와 develop 양쪽에 병합한다.

master는 실제 배포 버전을 관리한다. 항상 프로덕션 배포가 가능한 상태여야 하며, 배포 버전에는 태그를 붙여 관리한다.

hotfix는 배포 중인 코드에서 심각한 버그가 발견됐을 때 사용한다. master에서 직접 분기하고, 수정이 끝나면 master와 develop에 모두 반영한다.

브랜치가 합쳐지는 경로

⤢✕

기능 변경은 develop에서 시작한다

기능 개발은 develop에서 별도의 feature 브랜치를 만드는 것으로 시작한다. 작업이 끝난 feature 브랜치는 develop으로 병합하고 삭제한다.

⤢✕

먼저 develop에서 기능 브랜치를 만든다.

git checkout develop
git checkout -b feature/new-login

기능 구현은 여러 커밋으로 진행한다.

# 여러 작업 및 커밋
git add .
git commit -m "로그인 화면 구현"

개발이 끝나면 develop으로 병합한 뒤 기능 브랜치를 정리한다.

git checkout develop
git merge --no-ff feature/new-login
git branch -d feature/new-login

배포 준비 동안에는 새 기능을 멈춘다

릴리스 브랜치는 develop의 현재 상태를 배포 후보로 고정하는 역할을 한다. 이 단계에서는 버그 수정과 문서 업데이트를 진행하고, 새 기능은 넣지 않는다.

⤢✕

release 브랜치는 develop에서 생성한다.

git checkout develop
git checkout -b release/v1.0.0

배포 준비 과정에서 필요한 수정 사항을 커밋한다.

# 버그 수정 작업
git commit -m "로그인 실패 시 오류 메시지 수정"

완료된 release 브랜치는 master와 develop에 모두 병합하고 태그를 생성한다.

# master에 병합
git checkout master
git merge --no-ff release/v1.0.0
git tag -a v1.0.0

# develop에도 병합
git checkout develop
git merge --no-ff release/v1.0.0

# 릴리스 브랜치 삭제
git branch -d release/v1.0.0

운영 중인 결함은 master에서 바로 고친다

배포된 코드에서 심각한 버그가 발견되면 hotfix 브랜치를 master에서 직접 분기한다. 수정 내용은 다음 배포를 위한 develop에도 되돌려야 한다.

⤢✕

master에서 hotfix 브랜치를 생성한다.

git checkout master
git checkout -b hotfix/v1.0.1

긴급 수정은 해당 브랜치에서 커밋한다.

# 긴급 수정 작업
git commit -m "보안 취약점 수정"

수정이 끝나면 master와 develop 모두에 병합하고 브랜치를 삭제한다.

# master에 병합
git checkout master
git merge --no-ff hotfix/v1.0.1
git tag -a v1.0.1

# develop에도 병합
git checkout develop
git merge --no-ff hotfix/v1.0.1

# hotfix 브랜치 삭제
git branch -d hotfix/v1.0.1

Git-flow가 맞는 프로젝트와 운영 조건

정해진 일정에 따라 릴리스하는 프로젝트, 견고한 코드베이스가 필요한 의료 시스템이나 금융 애플리케이션, 월간 또는 분기별 릴리스 계획이 있는 프로젝트에 잘 맞는다. 여러 개발자가 참여하는 대형 프로젝트에서도 브랜치별 책임을 분명히 할 수 있다.

기업용 ERP·CRM 솔루션, 설치형 데스크톱 애플리케이션, 정기 패치와 업데이트가 필요한 게임, 펌웨어와 하드웨어 제어 소프트웨어 같은 임베디드 시스템도 적용 대상이 될 수 있다.

다만 소규모 팀에서는 브랜치 구조가 과도한 복잡성이 될 수 있다. 빠른 릴리스가 필요한 프로젝트나 지속적 배포가 중심인 웹 애플리케이션이라면 간소화된 전략을 검토할 필요가 있다. 팀의 작업 방식과 브랜치 규칙이 맞물리는지도 함께 판단해야 한다.

도입할 때 먼저 맞춰둘 기준

팀 구성원이 브랜치 전략을 이해하도록 교육하고, 일관된 작업 방식을 문서화하는 과정이 필요하다. 처음부터 전체 프로젝트에 적용하기보다 작은 기능부터 사용하며 경험을 쌓을 수 있다.

git-flow 확장 도구는 다음처럼 설치하고 초기화한다.

# 설치
apt-get install git-flow  # Ubuntu
brew install git-flow     # macOS

# 프로젝트 초기화
git flow init

확장 명령어를 사용하면 기능 브랜치의 시작과 종료를 더 직관적으로 처리할 수 있다.

# 기능 개발 시작
git flow feature start new-feature

# 기능 개발 완료
git flow feature finish new-feature

브랜치별 자동 빌드와 테스트를 CI/CD 파이프라인에 연결하고, 병합 전에 필수 코드 리뷰 절차를 두는 방식도 함께 운영할 수 있다.

더 단순한 브랜치 모델이 필요한 경우

Git-flow는 작은 프로젝트나 빠른 개발 사이클에서는 오버헤드가 될 수 있다. 엄격한 규칙이 개발 속도를 낮출 가능성도 있으며, 지속적 배포 중심의 CI/CD 파이프라인과 완전히 조화되지 않을 수 있다.

GitHub Flow는 master와 feature 브랜치로 구성되는 더 단순한 모델이다. 지속적 배포에 적합하고 풀 리퀘스트 중심으로 동작한다.

GitLab Flow는 Git-flow와 GitHub Flow의 중간 형태로, production·staging 같은 환경별 브랜치를 추가하며 이슈 트래킹과 긴밀하게 통합한다.

트렁크 기반 개발은 모든 개발자가 단일 브랜치인 trunk에 통합하는 방식이다. 작은 단위의 빈번한 커밋을 권장하고, 기능 플래그로 기능을 제어한다.

브랜치 전략은 목적 그 자체가 아니라 팀의 효율성과 코드 품질을 위한 수단이다. 프로젝트 성격, 팀 규모, 릴리스 주기에 맞춰 선택하거나 조정해야 한다.