이 문서는 가리사니 개발자 포럼에 올렸던 글의 백업 파일입니다. 오래된 문서가 많아 현재 상황과 맞지 않을 수 있습니다.
git 탐구 시리즈
서론
사실 플로우는 프로젝트의 유형이나 변경 수정사항등에 따라 구현할 수 있는 방법이 무궁무진합니다. 즉, 이번장의 설명은 수많은 방법중 하나입니다.
플로우
그림출처 : http://nvie.com/posts/a-successful-git-branching-model/
구글에 git flow를 검색하면 일반적으로 볼 수 있는 플로우 입니다.
상당히 복잡한 것 같지만 대규모 프로젝트에 가장 적합한 플로우 입니다.
그림을 설명해보겠습니다.
마스터 브랜치
사이클 : 프로젝트가 폐기될때까지.
말그대로 마스터이며, 최종 결과물을 커밋합니다.
MVC 패턴에서 컨트롤러가 컨트롤만 담당해야하듯 마스터 브랜치는 오직 병합과 버전(태그)만 관리되어야 합니다.
디벨롭 브랜치
사이클 : 최종 배포까지 (하나의 기획안이 완전히 끝날때까지)
하나의 프로젝트 단위를 받았을 경우 생성합니다.
예를들어 기획문서에의해 게시판이 변경되고 회원정보 변경 새로운 기능추가 등을 받았을대 생성합니다.
또한 생성전에 태그를 붙여 이전버전의 상태를 기록하는 것이 좋습니다. (핫픽스에서 설명)
피쳐 브랜치
사이클 : 디벨롭 브랜치에 영향을 줄 수 있는 하나의 단위가 끝날때까지.
디벨롭의 범위가 개발자간 상호간 영향을 끼치지 않으며, 완전한 폭포수 모델로 더 이상 변경사항이 없을 땐 생성하지 않아도됩니다. (다만 그런일은 거의 일어나지 않습니다.)
예를들어 기획문서상 어떠한 기능을 변경해야하는데 해당 기능이 변경될 경우 전체 디벨롭에 영향을 주기 때문에 다른 개발자가 영향이 생길 수 있다면 이 피쳐 브런치를 생성하여 작업이 완료될 때까지 유지하다가 디벨롭에 병합합니다.
또한 피쳐나 핫 픽스 같은경우는 여러개의 브랜치를 만들어 각자 작업하고 병합하기 알맞습니다.
핫픽스 브랜치
사이클 : 해당 기능이 수정될때까지
매우 흔한일로 개발자들이 하나의 프로젝트를 진행하는 도중에 기존 프로젝트의 변경사항이 생기는 일이 있습니다.
위 마스터에서 데브를 분할하기전 태그를 만들어 두었다면 해당 태그를 보고, 현재 상용으로 돌아가는 프로젝트 기점을 빠르게 판단하고 해당 지점으로부터 핫픽스 브랜치를 만들고 작업 후 마스터와 디벨롭에 병합 할 수 있습니다.
만일 핫픽스를 따로 만들지 않고 피쳐와 같은위치에 핫픽스를 만들경우 병합시 혼란스러운 상황이 발생할 수 있습니다.
릴리즈 브랜치
사이클 : 중간 배포할 디벨롭 브런치를 받아 버그수정 후 중간 배포가 완료될 때까지
기획안이 나오고 해당 기획안이 완료될때까지 핫픽스를 제외한 중간배포가 일어나지 않는다면 이 브랜치를 생성하지 않아도 됩니다.
예를들어 개발단위 도중 현재 개발진행을 상용에 중간 배포해야하는 경우 릴리즈 브랜치를 만듭니다.
릴리즈 브랜치에서는 오직 테스트 및 버그수정만 일어나야하며 이 작업이 완료된경우 마스터와 디벨롭(버그수정적용)에 병합합니다.
만일 릴리즈가 완료되고 중간 배포를 했다면 마스터에 병합 후 다시 태그를 만들어 주는 것이 핫픽스 문제를 줄일 수 있습니다.