Git-flow 브랜치 전략은 2010년 Vincent Driessen의 블로그로부터 시작되었고, 현재 Git 브랜칭 전략 중 유명한 브랜칭 전략이다. Git flow에는 다섯 종류의 브랜치가 존재한다. 항상 존재하는 master(main), develop 브랜치와 일정 기간 동안 유지되는 보조 브랜치들 (feature, release, hotfix)가 있다.
master
: 제품으로 출시될 수 있는 브랜치develop
: 다음 출시 버전을 개발하는 브랜치feature
: 기능을 개발하는 브랜치release
: 이번 출시 버전을 준비하는 브랜치hotfix
: 출시 버전에서 발생한 버그를 수정 하는 브랜치그림을 명확히 이해하기 위해서 시간의 흐름대로 차근차근 살펴보는 것이 좋다. master
는 main
으로 develop
은 dev
로 작성했다. 대략적인 흐름은 다음과 같다.
main
에서 dev
브랜치를 생성한다. dev
에서 feature
브랜치를 생성한다. feature
에서 dev
로 merge된다. dev
에서 release
브랜치를 생성한다. realease
에서 수정한다. release
브랜치를 main
과 dev
에 merge한다.main
브랜치에 버전 태그를 추가한다. Git flow는 대규모 프로젝트를 제작하여 하나의 소프트웨어 릴리즈 버전을 명확하게 나누는 당시의 개발 환경에 적합했지만 당시와 달리 빠르게 제작하고 배포하는 애자일 팀에게 적용하기는 복잡하게 느껴질 수 있다. 프로젝트 상황에 맞는 git-flow 협의가 필요한 부분이다.
이런 소프트웨어(웹 애플리케이션)는 내가 2010년 작성했던 블로그에서 생각했던 타입의 소프트웨어가 아니다. 당신의 팀이 지속적 배포를 원한다면, Github flow와 같은 간단한 워크플로우 도입을 제안한다. 굳이 애써 git-flow를 우겨넣지 않아도 된다.
_2020년 5월에 추가된 원문의 코멘트
Git flow에서 파생된 여러 Git flow 중에 대표적으로 Github flow, Gitlab flow가 있다. pre-project를 진행하며 코드스테이츠에서 제안한 git flow는 위 Git flow를 단순화한 Coz’ Git flow이다.
관련해서 간략하게 정리해보면,
핵심 브랜치 main
과 dev
브랜치를 둔다. main
은 상용으로 배포할 수 있는 브랜치이며, dev
는 다음 버전 배포를 위해 개발 중인 브랜치이다. main
브랜치로 배포하기 전에 확인해야 할 것들은 다음과 같다.