GitHub 기반 브랜치 명명 규칙 (Branch Naming)

Photo by Yancy Min on Unsplash

개요

GitHub을 활용하는 연습을 하고 있다. Subversion과는 많이 다른 것 같다. 게다가 혼자서 진행하다 보니 브랜치 이름이나 커밋 메시지 등에 일관성이 없어 불만스럽기도 하고. 뭔가 정리된 것이 있지 않을까 찾아보다가 'A successful Git branching model' 이란 글을 봤는데, Git 기반 개발 과정의 개념 정립에 큰 도움이 되는 글이었다. 이를 기반으로 나름대로 브랜치 명명규칙을 정의하다가, 우연히 'Miro Community'라는 오픈소스 프로젝트에서 정리한 'Git Branching Model' 이란 글을 보았다. 오, 좋은걸! 이걸 토대로 GitHub에서 개인 프로젝트를 진행할 때의 브랜치 명명 규칙을 정리했다. 

전제 조건

모든 활동은 GitHub에서 제공하는 Issue로 등록한다. hotfix, feature, issure 브랜치는 GitHub에 등록된 <issue_number>를 기준으로 생성한다. 

GitHub 설정

GitHub에는 master와 develop 브랜치, 그리고 master 브랜치의 TAG만 관리한다. 

• GitHub에 새 저장소를 생성한다. 
• 기본으로 master 브랜치가 생성된다. 
• 소프트웨어 배포 버전을 관리하며, 배포된 버전의 태그만 부여한다. 
• 태그 명명규칙: REL-X.X
• master 브랜치로부터 develop 브랜치를 생성한다. 
• 개발용 메인 브랜치로 활용한다. 

개발자 PC

개발자는 PC에 realease, hotfix, feature, issue 브랜치를 생성하여 작업을 진행한다. 작업이 완료된 브랜치는 병합 후 삭제 가능하며, GitHub에 반영하지 않는다. 

release 브랜치

• develop 브랜치로부터 생성하는 브랜치이다. 
• 명명규칙: release/X.X.X
• 브랜치 생성 후에는 버그픽스만 반영한다. 
• 최종 확정 후에는 develop와 master 브랜치에 병합한다. 
• master 브랜치에 병합 후 태그를 부여한다. 

hotfix 브랜치

• master 브랜치로부터 생성하는 브랜치이다. master 브랜치에 심각한 오류가 있는 경우에만 생성한다. 
• 명명규칙: hotfix/<issue_number>
• 완료 후 master, release, develop 브랜치에 병합한다. 

feature 브랜치

• develop 브랜치로부터 생성하는 브랜치이다. 
• 명명규칙: feature/<issue_number>/<짧은설명> 
• 완료 후 develop 브랜치에 병합한다. 

issue 브랜치

• develop, feature, release 브랜치로부터 생성하는 브랜치이다. 
• 명명규칙: issue/<issue_number>
• 완료 후에는 생성된 부모 브랜치로 병합한다.