혼자 개발을 한다면, 개인의 스타일의 Git을 사용합니다. 하지만 다양한 개발자간 협업을 한다면, 서로 규칙을 정해서 Git을 사용하게 됩니다. 이를 Git브런치 전략이라고 부르고 최근 Git-flow, Github-flow가 많이 사용됩니다.
Git-flow는 대표적인 branching 전략중 하나로 2010년 Vicent Driessen 작업 절차에 대해 소개합니다. Git-flow는 브랜치를 크게 4가지로 나누어 개발하는 전략입니다. master
와 develop
라는 항상 존재하는 메인 브랜치(Main branch)가 있고 feature
, hotfix
, release
라는 필요에 따라 생성하는 브랜치가 있습니다. 이후 imporvement
, bugfix
등 프로젝트에 따라 다양한 브렌치 모델이 추가되었습니다. 가장 중심이 되는 브랜치는 master와 develop 브랜치이며 merge된 feature, release, hotfix 브랜치는 삭제 합니다.
feature > develop > release > hotfix > master
순서로 앞에서 뒤로 진행된다.
relase브런치와 hotfix브런치의 경우, develop 브런치의 오른쪽에 존재하기떄문에 모두 develop 브런치도 머지를 하도록 구성됬다.
개발자는 각 작업에 따라 feature
브런치를 만들고 develop
브런치에 merge하는 순서로 진행해 작업을 분리하고 작업을 관리 할 수 있다.
메인 브랜치는 master
브랜치와 develop
브랜치 두 종류를 말한다.
master브랜치는 배포 가능한 상태만을 관리하는 브랜치를 말하며, develop 브랜치는 다음에 배포할 것을 개발하는 브랜치이다. 즉 develop 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행한다.
보조 브랜치는 feature branch
또는 topic branch
를 말한다.
master브랜치를 만들었고 develop브랜치를 만들었고 develop브랜치에서 다시 feature 브랜치를 나눠 작업을 하는것을 그림을 통해 알 수 있습니다. feature
또는 topic
브랜치는 기능을 개발하는 브랜치 입니다.
만약 feature 브랜치를 사용한다면 feature/#issue-Number
와 같은 형태로 사용합니다.
릴리즈 브랜치는 배포를 위한 최종적인 버그 수정을 등의 개발을 수행하는 브랜치를 말합니다.
develop 브랜치에 버전에 포함되는 기능이 merge되었다면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성합니다. 배포 가능한 상태가 되면 master 브랜치로 병합시키고, 출시된 master브랜치에 버전 태그 (eg. v1.0, v2.0)을 추가합니다. release 브랜치에서 발견된 버그 수정 사항은 Develop 브랜치에도 적용해줘야 하기떄문에 배포 완료 후 Develop 브랜치에 대해서도 Merge작업을 수행합니다.
핫픽스 브랜치는 배포한 버전에서 긴급하게 수정할 필요가 있을떄 master 브랜치에서 분리하는 브랜치를 말합니다.
버그를 잡는 사람이 일하는 동안에도 다른 사람들은 Develop 브랜치에서 작업을 할 수 있습니다. 이떄 hotfix브랜치에서의 변경 사항은 Develop 브랜치에도 merge 하여 문제가 된 부분을 합쳐줍니다.
장점
단점