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 브랜치로 배포하기 전에 확인해야 할 것들은 다음과 같다.