브랜치의 종류

다음은 "A successful Git branching model" 이란 컬럼에 소개된 4가지 브랜치 모델이다.

원문 : http://nvie.com/posts/a-successful-git-branching-model/

메인 브랜치(Main branch)

'master' 브랜치와 'develop' 브랜치를 보통 메인 브랜치로 사용한다.

• master

  'master' 브랜치는 배포 가능한 상태만을 관리한다. 커밋할 때는 태그를 사용하여 배포 번호를 기록한다.

• develop

  'develop' 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행하며 모든 기능이 정상적으로 동작할 수 있는 안정적인 상태를 유지해야 한다. 모든 기능이 추가되고 버그가 수정되어 배포 가능한 상태라면 'master' 브랜치에 merge 한다.

피쳐 브랜치(Feature branch)

• develop 브랜치에서 분기
• develop 브랜치로 merge
• 브랜치 이름은 master, develop, release-(RB_), or hotfix- 제외한 어떤한 이름도 가능

feature 브랜치는 토픽 브랜치의 역할을 담당한다.

이 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 'develop' 브랜치로부터 분기한다. feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에, 원격으로 관리하지 않는다. 개발이 완료되면 'develop' 브랜치로 병합하여 다른 사람들과 공유한다.

feature 브랜치는 다음과 같이 'develop' 브랜치에서 분기한다.

$ git checkout -b myfeature develop

feature 브랜치에서 모든 작업이 끝나면 다음과 같이 'develop' 브랜치로 merge하고 더이상 필요하지 않은 feature 브랜치는 삭제한다.

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

위 코드에서 --no-ff 플래그를 주목하자

`--no-ff' 플래그는 새로운 커밋 객체를 만들어 'develop' 브랜치에 merge한다. 이것은 feature 브랜치에 존재하는 커밋 이력을 모두 합쳐서 하나의 새로운 커밋 객체를 만들어 'develop' 브랜치로 merge 되는 것이다.

릴리즈 브랜치(Release branch)

• develop 브랜치에서 분기
• develop 브랜치와 master 브랜치로 merge
• 브랜치 이름은 release-(RB_)*

Release 브랜치에서는 버그를 수정하거나 새로운 기능을 포함한 상태로 모든 기능이 정상적으로 동작하는지 확인한다. Release 브랜치의 이름은 관례적으로 브랜치 앞에 'RB_' 접두어를 붙인다. 이때, 다음 번 Release를 위한 개발 작업은 'develop' 브랜치에서 계속 진행해 나간다.

Release 브랜치에서는 Release를 위한 최종적인 버그 수정 등의 개발을 수행한다. 모든 준비를 마치고 배포 가능한 상태가 되면 'master' 브랜치로 병합시키고, 병합한 커밋에 Release 번호 태그를 추가한다.

Release 브랜치에서 기능을 점검하며 발견한 버그 수정 사항은 'develop' 브랜치에도 적용해 주어야 한다. 그러므로 배포 완료 후 'develop' 브랜치에 대해서도 병합 작업을 수행한다.

release 브랜치 만들기

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

release 브랜치 종료 와 merge

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).

핫픽스 브랜치(Hotfix branch)

• master 브랜치에서 분기
• develop 브랜치와 master 브랜치로 merge
• 브랜치 이름은 hotfix-*

배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, 'master' 브랜치에서 분기하는 브랜치입니다. 관례적으로 브랜치 이름 앞에 'hotfix-'를 붙인다.

예를 들어 'develop' 브랜치에서 개발을 한창 진행하고 있는 도중에 이전에 배포한 소스코드에 아주 큰 버그가 발견된 경우 문제가 되는 부분을 빠르게 수정해서 안정적으로 다시 배포해야 한다. 'develop' 브랜치에서 문제가 되는 부분을 수정하여 배포 가능한 버전을 만들기에는 시간도 많이 소요되고 안정성을 보장하기도 어려우므로 바로 배포가 가능한 'master' 브랜치에서 직접 브랜치를 만들어 필요한 부분 만을 수정한 후 다시 'master'브랜치에 병합하여 이를 배포해야 하는 것이다.

이 때 만든 핫픽스 브랜치에서의 변경 사항은 'develop' 브랜치에도 병합하여 문제가 되는 부분을 처리해 준다.

hotfix 브랜치 만들기

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

hotfix 브랜치 종료와 merge

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)