Branch 생성 방식과 네이밍 규칙

클론 코딩을 시작하려는데, 현업에서 하는 것처럼 브랜치를 나눠서 하려니 브랜치 이름에도 규칙이 있지 않을까 싶어 찾아보고 작성합니다.

더불어, 브랜치 네이밍을 알기에 앞서 브랜치 종류는 어떤 것이 있는지 먼저 설명하겠습니다.

---

Bracnh의 종류

Main branch

중앙 저장소에는 수명이 무한한 두 가지 메인 브랜치가 있다.
바로, master 브랜치와 develop 브랜치이다.

1. master branch

제품으로 출시될 수 있는 브랜치

사용자에게 배포 가능한 상태만을 관리한다. 여기서는 배포(release) 이력을 관리하기 위해 사용한다.

즉, 함부로 master 브랜치에 병합(merge) 하게 되면 탕비실에 끌려갈 수 있다. 항상 master 브랜치에서 작업하고 있는 건 아닌지 확인하는 습관을 가지자.

2. develop branch

다음 출시 버전을 개발하는 브랜치

기능 개발을 위한 브랜치들을 병합하기 위해 사용한다. 즉, 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 mater 브랜치에 merge(병합)한다.
평소에는 이 브랜치를 기반으로 개발을 진행한다.

Supporting branches

우리는 앞으로 다양한 supporting 브랜치를 사용하여 팀 구성원 간에 평행 개발을 할 수 있고, 기능을 쉽게 추적할 수 있다. 또, 여러 가지 문제도 해결하기 쉬워진다. 이 supporting 브랜치들은 메인 브랜치와는 달리 결국 제거될 것이기 때문에 항상 제한된 수명을 갖는다.

supporting 브랜치는 세 가지가 있다.

1. feature branch

기능을 개발하는 브랜치

feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 develop 브랜치로부터 분기한다. feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에 자신의 로컬 저장소에서 관리한다.

개발이 완료되면 develop 브랜치로 merge하여 다른 사람들과 공유한다.

1. develop 브랜치에서 새로운 기능에 대한 feature 브랜치를 분기한다.
2. 새로운 기능에 대한 작업을 수행한다.
3. 작업이 끝나면 develop 브랜치로 merge 한다.
4. 더 이상 필요하지 않은 feature 브랜치는 삭제한다. - 많은 줄기(branch)는 작업에 혼란을 줄 수 있다.
5. 새로운 기능에 대한 feature 브랜치를 중앙 원격 저장소에 올린다.

//develop 브랜치에서 생성
$ git checkout -b feature/login develop

2. release branch

이번 출시 버전을 준비하는 브랜치

배포를 위한 전용 브랜치를 사용함으로써 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능 개발을 계속할 수 있다. 1팀은 1.2버전을 개발하고, 2팀은 1.3버전을 개발할 수 있다.

release 브랜치는 배포를 위한 최종적인 버그 수정, 문서 추가 등 배포와 직접적으로 관련된 작업을 수행한다. 이러한 작업들 이외에 release 브랜치에 새로운 기능을 추가로 merge하지 않는다.

3. hotfix branch

출시 버전에서 발생한 버그를 수정하는 브랜치

배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, master 브랜치에서 분기하는 브랜치이다. develop 브랜치에서 문제가 되는 부분을 수정하여 배포 가능한 버전을 만들기에는 시간도 많이 소요되고 안정성을 보장하기도 어려우므로 바로 배포가 가능한 master 브랜치에서 직접 브랜치를 만들어 필요한 부분만 수정한 후 다시 master 브랜치에 병합하여 이를 배포하는 것이다.

1. 배포한 버전에 긴급하게 수정할 부분 발생 => master브랜치에서 hotfix브랜치 분기

2. 문제가 되는 부분 수정후, master브랜치에 merge하고 배포

3. hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge한다.

버그 수정만을 위한 Hotfix 브랜치를 따로 만들었기 때문에, 다음 배포를 위해 개발하던 작업 내용에 전혀 영향을 주지 않는다. hotfix는 master브랜치에서 분리한 임시 브랜치라고 생각하면 된다.

branch 네이밍 규칙

어떤 방식으로 브랜치의 이름을 정하는지 브랜치 종류에 따라 살펴보자.

1) master branch, develop branch

master와 develop 브랜치는 본래 이름 그대로 사용하는 경우가 일반적이다.

2) feature branch

• 어떤 이름도 가능하다. 단, master, develop, release-..., hotfix-... 같은 이름은 사용할 수 없다.

• feature/기능요약 형식을 추천한다. ex) feature/login

• feature/{issue-number}-{feature-name} 이슈추적을 사용한다면 이와 같은 형식을 따른다.
  ex) feature/1-init-project, feature/2-build-gradle-script-write

3) release branch

• release-RB_... 또는 release-... 또는 release/...같은 이름이 일반적이다.

• release-... 형식을 추천한다. ex) release-1.2

4) hotfix branch

• hotfix-... 형식을 추천한다. ex) hotfix-1.2.1

References

• https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html

• https://nvie.com/posts/a-successful-git-branching-model/