Vincent Driessen의 a-successful-git-branching-model 을 정리한 글입니다.
🔗a-successful-git-branching-model
Git Flow 전략엔 5가지 핵심 브랜치가 존재한다!
이는 각각 master, develop, feature, release, hotfix이다.
각 브랜치의 역할과 흐름을 알아보자!

📌메인 브랜치
중앙 저장소에 무기한 보존되는 두 개의 핵심 브랜치이다.
master 브랜치 - 제품 출시
: 중앙 저장소에 무기한 보존되는 주요 브랜치이며, 실제 사용 가능한 상태를 반영하는 메인 브랜치이다. 변경 사항이 merge 될 때마다 새로운 버전 릴리즈는 master 브랜치의 것이다.
실제 사용자에게 배포되는 가장 안정적인 상태를 유지한다.
develop 브랜치 - 다음 릴리즈 준비
: master 브랜치처럼 중앙 저장소에 무기한 보존되는 주요 브랜치로, 다음 릴리즈를 위한 최신 개발 변경 사항이 항상 반영되어 있다. 통합 브랜치라고도 불린다. develop 브랜치의 소스 코드가 안정화되어 릴리즈 준비가 완료되면, 모든 변경 사항을 master 브랜치로 병합한 다음에 릴리즈 번호(태그)를 지정해야 한다.
📌보조 브랜치
메인 브랜치인
master,develop브랜치 외에도 팀 구성원 간의 병렬 개발을 지원하고 기능 추적을 용이하게 하는 등 다양한 보조 브랜치를 사용한다.
feature 브랜치 - 새 기능 개발
: 향후 릴리즈될 버전이나 먼 미래의 버전을 위한 새 기능을 개발하는 데 사용한다.develop 브랜치에서 분기될 수 있으며, 다시 develop 브랜치로 병합해야 하는 브랜치로,master, develop, release, hotfix를 제외한 모든 것이다.
release 브랜치 - 새 출시 버전 준비
: 새로운 프로덕션 릴리즈를 준비하는 브랜치이다. release 브랜치를 통해 최종 단계에서 세부적인 사항을 확인하고, 사소한 버그를 수정하거나 릴리즈에 필요한 메타데이터를 준비할 수 있다.
이러한 모든 작업을 release 브랜치에서 완료하면, develop 브랜치는 다음 주요 릴리즈에 포함될 새로운 기능을 추가할 준비가 된다.develop 브랜치에서 분기될 수 있으며, 다시 develop 그리고 master 브랜치로 병합해야하는 브랜치로, release-*의 형식으로 명명된다.
hotfix 브랜치 - 출시 버전에서의 버그 수정
: 계획되지 않은 새로운 프로덕션 릴리즈를 준비하기 위한 브랜치이다. 실제 운영 중인 프로덕션 버전에서 바람직하지 않은 상태가 발생했을 때 즉시 조치를 취해야 한 경우에 사용한다. 심각한 버그를 즉시 해결해야 할 경우, 해당 프로덕션 버전을 나타내는 master 브랜치의 태그에서 분기한다. 팀 구성원들이 develop 브랜치에서 작업을 계속하는 동안 다른 사람이 신속하게 운영 환경 개선을 준비 가능하다.
💡요약
master브랜치에서develop브랜치를 분기한다.develop브랜치에서 상시로 버그를 수정한 커밋이 추가된다.feature브랜치에서 새 기능을 개발하고, 기능 추가 작업이 완료되었다면develop브랜치로 merge 한다.develop브랜치에 새로이 추가될 기능이 merge 되었다면 QA를 위해release브랜치를 분기한다.- QA를 진행하며 발생된 버그들은
release브랜치에서 수정한다. - QA를 무사히 통과했다면
release브랜치를master&develop브랜치로 merge 한다. - 마지막으로 출시된
master브랜치에 버전 태그를 추가한다. - 새 버전을 출시하고 운영 중에 급한 버그가 발견되면
master에서hotfix를 분기해 수정 후master와develop모두에 병합한다.
참고: [a-successful-git-branching-model],
[우아한 기술블로그 - 우린 Git-flow를 사용하고 있어요]
'WEB' 카테고리의 다른 글
| [Git&Github] Branch Merge 방법 (0) | 2026.06.01 |
|---|---|
| [Git&Github] Git Branch와 Merge (0) | 2026.06.01 |