Git Flow 브랜치 전략은 2010년 Vincent Driessen이 자신의 블로그 nvie.com에 제시한 브랜치 관리 모델이다. 이 모델은 git을 사용하면서 생기는 커밋들을 어떻게 관리할지 보여준다. 팀원 개개인이 브랜치를 복사해서 쓸 수 있어서 git은 탈중앙화 되어 보이지만, 해당 모델은 중앙에 위치하는 브랜치를 정하도록 한다.
git flow가 제시하는 브랜치 종류는 다섯 가지가 있다. master, develop, feature, release, hotfix라는 이름으로 다섯 개의 브랜치가 있고, 그 중에서 master와 develop은 항상 유지하는 브랜치, 가장 중심이 되는 브랜치다.
master는 실제 사용자들이 쓰는 코드가 담기는 브랜치다. 정식 출시 한 소프트웨어가 이 브랜치에 담긴다. 정식 릴리즈나 치명적인 오류가 발생할 때 커밋하는 브랜치이기 때문에 이 브랜치에는 커밋을 많이 할 일이 없어야 한다.
develop은 다음 릴리즈를 위해 개발한 기능들을 모아두는 브랜치이다. feature 브랜치에서 테스트되고 시도된 기능 중에 성공적인 기능들, release 브랜치의 커밋들, hotfix의 커밋들 모두 최종적으로 develop 브랜치에 merge 해서 가장 중앙에서 가장 최신화된 기능들이 모여 있게 된다.
feature 브랜치에서는 여러 기능들을 시험하는데, 쓸 만한 기능들, 다음 릴리즈에 추가해야 할 기능들 등이 테스트된다. 메인 팀 하위의 작은 팀들이 만들어져서 develop 브랜치의 커밋들을 가져와서 feature 브랜치에서 테스트할 수 있다. master와 develop 두 개를 제외한 feature, release, hotfix 브랜치는 임시적인 것들로, 어느 feature 브랜치에서 그 목적을 다했다면 해당 브랜치는 삭제한다.
release 브랜치는 다음 릴리즈에 담길 기능들이 develop 브랜치에서 모두 만들어지고 다음 버전을 릴리즈하기 위해 준비하는 브랜치이다. develop 브랜치에서 release 브랜치가 만들어질 때에야 버전 넘버를 부여한다. develop 브랜치는 계속해서 개발이 이루어지기 때문에 버전 넘버를 붙이기가 애매하기 때문이다. 분기된 release 브랜치에서는 큰 변경사항을 적용하지 않는다. 마이너한 버그 수정만이 이루어진다. 그 밖에 릴리즈 날짜 등의 메타 데이터를 입력한다. 정식 출시가 되면 master 브랜치로 merge 함과 동시에 develop 브랜치로도 merge 해서 두 개의 중심 브랜치가 업데이트 되도록 하고 해당 release 브랜치는 삭제한다.
hotfix 브랜치는 master 브랜치에서 분기되어서 나오는데, 이런 경우는 다음 릴리즈에 포함될 사항과 관련 없는 버그나, 예상치 못한 버그, 긴급한 수정 사항 등이 발생했을 때에 해당한다. hotfix로 버그를 수정하면 다시 master 브랜치로 merge 하고 또한 develop 브랜치에도 merge 해야 한다. master 브랜치로 머지할 땐 버젼 넘버를 수정해야 한다. hotfix 브랜치 또한 버그가 수정되면 삭제한다.
Vincent Driessen은 이 모델을 제시한 블로그 글에 2020년 추가적인 서문을 달았는데, 웹애플리케이션 등 지속적인 개발이 이루어지는 등의 소프트웨어는 그가 그 포스트를 쓸 때 염두에 두지 않은 것들이라 한다. git flow 가 만병통치약이 되지 않도록 경계해야 하고 본인의 팀의 맞는 전략을 생각해 볼 것을 권했다.
