Git 브랜치 네이밍과 사용 방법 (Git Branch Strategy)

일을 하다가 Git 브랜치 네이밍 규칙이 있음을 알게 되었다.

총 5가지의 브랜치가 있고 각 브랜치의 사용법에 대해 정리하려 한다.

 

Git Branch Strategy을 검색하면 제일 많이 나오는 사진.

한눈에 각 브랜치를 파악하기 좋은 이미지다. 

브랜치를 나눠서 사용하는 이유

여러 개발자가 하나의 저장소에서 개발을 해야 하는데

브랜치가 나눠져 있지 않으면, 혼란스럽고 효율적이지 못 할 것이다.

따라서 효과적으로 협업하기 위해 브랜치 생성 규칙을 사용한다.

 

브랜치 종류

#1. Master Branch

제품으로 출시되는 브랜치.

최종 라이브 배포 이력을 관리하기 위한 최상위 브랜치다.

 

#2. Develop Branch

다음 출시 버전을 대비하여 개발하는 브랜치.

feature 브랜치로부터 출시할 모든 기능이 머지되면 release 브랜치에 머지하고 QA 테스트를 진행한다.

 

#3. Feature Branch

기능 개발 브랜치. Develop 브랜치로부터 분기한다.

개발이 완료되면 Develop 브랜치로 머지한다.

 

동시에 여러 기능을 개발할 경우가 있으므로 각 기능별 major 브랜치를 생성해서 작업한다.

ex) feature/major-[개발할 기능]

 

생성한 major 브랜치를 기준으로 새로운 브랜치를 따서 작업을 진행한다.

작업이 완료되면 major 브랜치로 PR 한다.

 

#4. Release Branch

출시를 기다리는 브랜치.

QA Test 진행 이후 이상 없으면 제품으로 출시된다.

테스트에서 버그를 발견하면 release 기준 fix 브랜치를 따서 수정하고 PR 한다.

develop 브랜치에도 수정사항을 cherry-pick 한다.

 

제품 출시가 확정되면 Master Branch로 머지된다.

 

#5. Hotfix Branch

배포된 제품(master 브랜치)에서 발견한 버그를 수정하는 브랜치.

master 브랜치 기준으로 hotfix 브랜치를 생성한 다음, 버그를 수정한다.

버그가 수정되면 master 브랜치에 hotfix 브랜치를 머지한다.

develop 브랜치에도 버그 수정을 해야 하기 때문에 hotfix 브랜치를 develop 브랜치에 cherry-pick 한다.