우리는 기능을 하나씩 개발할 때, 혹은 협업을 할 때 깃의 브랜치를 활용한다. 브랜치를 활용하면 다른 브랜치에 영향을 받지 않고 여러 기능을 여러 사람들이 병렬적으로 개발할 수 있다.
하지만 협업을 할 때 특정한 규칙을 정해놓지 않으면 다음과 같은 의문점이 생길 수 있고, 이는 프로젝트 진행에 문제가 될 수 있다.
→ 이러한 문제점을 해결할 수 있는 것이 Git Branch 전략이다.
Branch 전략은 Git 브랜치를 효과적으로 관리하기 위한 워크플로어다. 거의 모든 기업들은 자신들의 상황에 맞는 Branch 전략을 사용하고 있다. 대표적인 Branch 전략에는 GitHub Flow, Git Flow, GitLab Flow 등이 있다. 이번 시간에는 그 중 Git Flow 전략에 대해 살펴볼 것이다.
깃플로우git-flow 전략은 소스코드를 관리하고 출시하기 위한 Git Branch 전략 중 하나다. Git flow는 2010년에 Vincent Driessen가 블로그에서 제안한 모델을 기반으로 만들어졌으며, 현재는 많은 기업에서 표준으로 사용하는 브랜치 전략이다.
Git Flow는 크게 Main 브랜치, Supporting 브랜치로 구분하여 브랜치를 관리한다.
하나의 새로 기능을 개발하기 위한 브랜치
브랜치가 분기되는 곳 : develop
브랜치가 머지 되는 곳 : develop
Develop에 merge 후 삭제한다.
네이밍 ex) feature/branch-name
다음 버전 출시를 위해 준비하는 브랜치
브랜치가 분기되는 곳 : develop
브랜치가 머지 되는 곳 : develop, master
버전 정보, 버그 수정 등의 QA(품질보증)을 진행한다.
Main 브랜치에는 tag를 이용해 버전을 표시한다.
기능 개발은 금지된다
네이밍 ex) release-*
이미 출시된 버전에서 버그가 발생하면 빠르게 수정하기 위해 생성하는 브랜치
브랜치가 분기되는 곳 : master
브랜치가 머지 되는 곳 : develop, master
코드를 수정하는 중에도 develop에서는 개발을 지속할 수 있다는 장점이 있다.
master브랜치에서 분기되며, 문제 해결이 완료되면 develop & master 브랜치로 merge한다.
master로 merge 후에는 tag를 통해 이전 버전보다 높은 버전을 명시한다.
네이밍 ex) hotfix-*
Git Flow 전략은 다음과 같이 소스 코드를 관리한다.
출처 : https://nvie.com/posts/a-successful-git-branching-model/
v1.1
버전이 올라와 있다.v1.2
개발중이다.feature/기능1
, feature/기능2
브랜치를 생성해서 각 기능별로 개발을 진행한다.v1.2
버전 태그를 추가한다.💡만약 이미 출시되어 있는 master 버전에서 버그가 발생하여 빠르게 수정해야 하는 경우 master 브랜치에서 hostfix 브랜치를 생성하여 오류를 수정한다. 오류 수정 후 master와 현재 개발 중인 develop 브랜치에 머지 한다.