[Git] Git flow

Git-Flow는 대표적인 브랜칭 전략 중 하나로 2010년 Vicent Driessen는 Git 작업 절차에 대해 소개합니다.

Git-Flow는 브랜치를 크게 4가지로 나누어 개발하는 전략입니다.

Git Flow 전략에는 master와 develop이라는 항상 존재하는 메인 브랜치가 있고,

feature-*, hotfix-*, release-* 라는 필요에 따라 생성하는 브랜치가 있습니다.

이후 improvement-*, bugfix- 등 프로젝트에 따라 다양한 브랜치 모델이 추가 되었습니다.

가장 중심이 되는 브랜치는 master와 develop 브랜치이며, merge된 feature, release, hotfix 브랜치는 삭제하도록 합니다.

 

메인 브랜치는 master 브랜치와 develop 브랜치 두 종류를 말합니다.

master 브랜치는 배포 가능한 상태만을 관리하는 브랜치를 말하며,

develop 브랜치는 다음에 배포할 것을 개발하는 브랜치입니다.

즉 develop 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행합니다.

 

보조 브랜치는 feature 브랜치 또는 topic 브랜치를 말합니다.

master 브랜치에서 develop 브랜치를 만들었고,

develop 브랜치에서 다시 feature 브랜치를 나눠 작업을 하고 있는 것을 알 수 있습니다.

feature 또는 topic 브랜치는 기능을 개발하는 브랜치입니다.

develop 브랜치에는 기존에 잘 작동하는 개발코드가 담겨있으며,

보조 브랜치는 새로 변경될 개발코드를 분리하고 각각 보존하는 역할을 합니다.

보조 브랜치는 기능을 다 완성할 때까지 유지하고,

다 완성되면 develop 브랜치로 merge 하고 결과가 좋지 못하면 버리는 방향을 취합니다.

보조 브랜치는 보통 개발자 저장소에만 있는 브랜치고, origin에는 push하지 않습니다.

만약 feature 브랜치를 사용한다면, feature/#이슈번호 와 같은 형태로 브랜치를 관리합니다.

 

릴리스 브랜치는 배포를 위한 최종적인 버그 수정 등의 개발을 수행하는 브랜치를 말합니다.

develop 브랜치에 버전이 포함되는 기능이 merge 되었다면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성합니다.

배포 가능한 상태가 되면 master 브랜치로 병합시키고, 출시된 master 브랜치에 버전 태그(ex v1.0, v0.2)를 추가합니다.

release 브랜치에서 기능을 점검하여 발견한 버그 수정사항은 develop 브랜치에도 적용해줘야 합니다.

그러므로 배포 완료 후 develop 브랜치에 대해서도 merge 작업을 수행합니다.

 

핫픽스 브랜치는 배포한 버전에서 긴급하게 수정할 필요가 있을 때 master 브랜치에서 분리하는 브랜치를 말합니다.

버그를 잡는 사람이 일하는 동안에도 다른 사람들은 develop 브랜치에서 하던 일을 계속할 수 있습니다.

이 때 만든 hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge하여 문제가 되는 부분을 처리해줘야 합니다.