[GIT] GIT branch strategy 명명규칙 및 전략

GIT branch 명명 규칙

만약 1~2명에서 하는 소규모 프로젝트에서 GIT을 사용하면 특별하게 규칙이라고 할것도 없습니다.
하지만 프로젝트 규모가 커지고 인원도 늘어나게되면 한가지 레파지토리내에서 일정한 규칙은 반드시 존재해야합니다.

단독적으로 프로젝트만들면 맘대로 해도되지만요.

그래도 국내에서 나 해외에서나 GIT을 통상적으로 사용하는 패턴을 소개하고자 합니다.
설명하게 앞서 지금 소개해드리는 내용은 이미 많은 블로그나 글들에 등록되어있는데 2010년에 ” https://nvie.com/posts/ ” 포스트에 실린 “A successful Git branching model” https://nvie.com/posts/a-successful-git-branching-model/에 관한 내용입니다.
GIT을 국내 프로젝트에서 많이사용하게 된 시점이 3~4년 전인걸 감안하면.. 앞으로 정보력이 생명… (앞으로도 열심히 )

Github 이나 Gitlab이나 똑같이 Branch 구조를 어떻게 생성하고 내려가는지 설명하겠습니다.
보통 Repository를 처음 만들고나면 Branch명은 Master 브랜치로 생성됩니다.
Master 브랜치에서는 최초 Initial 개념의 시작점이며
개발을 위해선 별도로 Develop이라는 브랜치를 하나 만들고 나아갑니다.

먼저 크게 브랜치 종류를 어떤식으로 생성하는지 설명하겠습니다.

MASTER / DEVELOP 가 대부분 기준점이자 시작점입니다.

Master (Main Branch)
Develop (Main Branch)
Feature/<Issue_number> or <Feature_name> / <Short Description>
Release/<version_number>
Hotfix/<Issue_number> or Issue/<Issue_number>

1. Master Branch

Release(배포)출시 할 수 있는 브랜치

최종 배포(Release) 이력을 관리하기 위한 최상위 브랜치입니다.
배포 가능한 상태만을 관리합니다.

2. Develop Branch

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

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

3. Feature branch

기능을 개발하는 브랜치 (Local)

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

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

‘develop’ 브랜치에서 새로운 기능에 대한 feature 브랜치를 분기한다.
새로운 기능에 대한 작업 수행한다.
작업이 끝나면 Local에서 개발한 Feature 브랜치를 develop에 병합한다.
더 이상 필요하지 않은 feature 브랜치는 삭제한다.
새로운 기능에 대한 ‘feature’ 브랜치를 중앙 원격(Remote) 저장소에 올린다.(push)

4. Release Branch

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

Feature branch에서 Develop 브랜치로 어느정도 배포가 진행되고 배포할 수있는 시점(모든 기능이 정상인 상태 or 목표개발기간종료) 이 되었을때 Release Branch를 생성합니다.
그 이후 테스트를 통해 최종적으로 버그 수정이라든가, 문서 추가등 실질적으로 Release 출시 하기 직전에 하는 단계들을 위한 브랜치 입니다. 만약 버그수정이 있다면 수정하고 Develop 에다가도 병합해줍니다.
기능에 대한 병합작업은 하지 않는 단계이며 마지막 검토 정도로 생각하면 될것 같습니다. 기능에 대한 개발은 계속해서 Develop 이나 Feature Branch에서 이어나갑니다.

그리고 모든 버그나 문서 수정이 완료 되면 Master Branch로 병합 및 버젼 Tag를 부여하여 출시 합니다.
또 배포를 준비하는동안에 Release 브랜치가 변경되었을 수 있기때문에 배포 완료후에 Develop 에다가도 병합합니다.

- EX) release/1.2
  * 소프트웨어 번호 관리는 보통 SemVer (Semantic Versioning의 줄임말) 버전의 형식은 [Major].[Minor].[Patch]

5. Hotfix Branch

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

배포를 했지만 갑작스럽게 수정해야하는 경우에 master에서 바로 수정하지 않고 Hotfix 브랜치를 분기하고 고친후 병합합니다. <master에서 수정하는일은 거의 없음, 분기후 수정>문제가 되는 부분만을 빠르게 수정한다.
존재의 이유는 갑작스럽게 수정해야 하는 부분이며 Patch 버젼(1.2.1)을 새롭게 변경해 줍니다.

그리고 배포가 끝난후 다시 develop에다가도 병합해 줍니다.

다음은 전체 흐름에 대한 설명입니다. 앞에서 설명한 내용에대한 각각의 브랜치를 생각하면서 하단 내요의 흐름을 보시면 이해가 잘 될겁니다.
이미지에 대체텍스트 속성이 없습니다; 파일명은 git-model@2x.png 입니다.

위에서 아래로 시간흐름입니다.
맨 오른쪽이 프로젝트를 처음 만든 Master 브랜치입니다.
첫 출발에 맞춰 시작점을 git Tag를 부여해 0.1로 기입하며 시작합니다. 그리고 develop이라는 개발 branch를 생성 그이후 기본적인 옵션이나 설정들을 해나가게 됩니다.
그리고 이제 팀프로젝트에서 기능별(상품,고객,주문배송) 및 개발파트별로 Feature branches를 생성(Local) 합니다. 그러면 각 파트별 개발자들은 개발들을 쭉쭉 이어나갑니다.
그러던 와중에 갑자기 무조건 고쳐야할 무언가가 대상이 발견됩니다. 바로 Master 브랜치에서 HotFix브랜치를 분기하고 고칩니다. 그리고 Master 브랜치에 병합하고 또 Develop 브랜치에도 병합합니다.

아까 Feature Branch에서 생성한 내용들이 어느정도 Master 브랜치에 병합되었고 이제 배포날짜가 다가옵니다. 어느정도 윤곽이 생겼고 기능들이 정상적으로 작동된걸 Develop 브랜치에서 확인한후 배포를 시작할 Release 브랜치를 생성합니다.
이 Release 브랜치는 1.0으로 Master 브랜치에 넘어가기 직전의 단계이며, 추가적으로 버그가 있는지 또는 문서작업이 필요한게 있는지 최종적으로 점검합니다.
모든 점검이 끝나고 드디어 Master 브랜치 1.0 으로 병합되어 개발싸이클이 끝나게 됩니다.
그리고 이런 싸이클이 진행되면서도 다른 Branch에서도 개발은 계속 이어나가게 됩니다.

너무 서술식으로 작성되어 이해가 어려울수도 있겠지만 대략적인 흐름에 대해서는 감이 오셨을거라고 생각합니다.

다음엔 좀더 쉽게 이해할 수 있도록 작성해 보겠습니다.

참고로 구글에서도 구글 브랜치 전략이라고 치면 다음과 같이 많은 내용들이 나오고 설명되어있으니 참고바랍니다.