Branch의 종류와 사용법

Git Branches

Git Workflow는 수명이 항상 유지되는 메인 브랜치(master, develop)와 일정 기간 동안만 유지되는 보조 브랜치(feature, release, hofix) 총 5개의 브랜치를 사용합니다. 아래 그림은 "A Successful Git brancing model" 글에 첨부된 이미지를 가져온 것으로, 이보다 더 Git Workflow를 잘 설명한 그림은 없는 것 같습니다 😀

메인 브랜치 (Main Branch)

< master branch >

master 브랜치는 배포 가능한 상태만을 관리하며, 커밋할 때는 태그를 사용해 배포(Release) 번호를 기록합니다. 위의 Workflow를 이용한 협업에서 작업한 결과물을 서브 브랜치가 아닌, master에 바로 올려 버리면 크게 혼날 수 있습니다.

현재는 기본 브랜치의 이름을 main으로 사용합니다. (master → main)

< develop branch >

develop 브랜치는 기능 개발을 위한 feature 브랜치들을 병합하기 위해 사용합니다. 평소에는 이 브랜치를 기반으로 개발을 진행하며, 모든 기능이 추가되고 버그가 수정되어 배포에 문제가 없을 때, master 브랜치에 병합하게 됩니다.

# develop 브랜치 생성 후 저장소에 올림
$ git branch develop
$ git push -u origin develop

보조 브랜치 (Supporting Branch)

< feature branch >

feature 브랜치는 새로운 기능을 개발하거나 버그를 수정할 필요가 있을 때마다 develop 브랜치로부터 분기합니다. 이 브랜치에서의 작업은 보통 공유할 필요가 없고 그 부분을 맡은 사람만 작업을 하게 되기 때문에, 로컬 저장소에서 관리하게 됩니다. 개발이 완료되면 develop 브랜치에 병합하여 다른 사람들과 공유하고, 해당 브랜치는 삭제합니다.

# feature/login 브랜치 생성 후 전환
$ git checkout -b feature/login develop

# 작업 수행 후 develop 브랜치로 이동 후 병합
$ git checkout develop
$ git merge --no-ff feature/login

# 구현이 끝난 브랜치 삭제 후 저장소에 올림
$ git branch -d feature/login
$ git push origin develop

git merge 명령의 --no-ff 옵션은 합치고자 하는 브랜치(feature/login)에 존재하는 모든 커밋 이력을 하나로 합쳐 새로운 커밋을 생성한 후 병합할 수 있도록 합니다. 하나의 기능을 구현할 때 너무 많은 커밋을 남기게 되면, 부모 브랜치와 병합하면서 불필요한 이력이 많아지기 때문에 정리하는 것입니다.

< release branch >

release 브랜치는 출시할 버전을 준비하는 브랜치입니다. 배포만을 위한 브랜치를 사용함으로써 배포를 준비 중인 팀은 이곳에만 집중하고, 다른 팀은 다음 배포를 위한 기능 개발을 이어갈 수 있습니다. 직접적으로 관련된 내용을 제외하고는 새로운 기능을 병합하지 않고, 버그 수정과 문서 작업 정도를 수행합니다.

모든 배포 준비가 완료되면 master 브랜치에 병합하며, 변경 사항이 있을 수 있기에 develop 브랜치에도 병합 후 삭제해 줍니다.

# release 브랜치 생성 후 전환
$ git checkout -b release-1.1 develop

# 배포 작업 수행 후 master 브랜치로 이동 후 병합
$ git checkout master
$ git merge --no-ff release-1.1
# 병합한 커밋에 Release 버전에 대한 태그 부여
$ git tag -a 1.1

# develop 브랜치에도 병합 후 삭제
$ git checkout develop
$ git merge --no-ff release-1.1
$ git branch -d release-1.1

< hotfix branch >

 

hotfix 브랜치는 출시 버전에서 발생한 버그를 빠르게 수정할 필요가 있을 때, master에서 분기하는 브랜치입니다. 문제가 되는 부분만을 빠르게 수정하여, 바로바로 동작할 수 있도록 해야 합니다. 문제를 해결했으면 master 브랜치에 병합하면서, 새로운 버전 이름으로 태그를 붙여 주면 됩니다. hotfix 브랜치의 변경 사항은 develop 브랜치에도 병합해야 하고, 그 이후에는 다른 보조 브랜치와 동일하게 제거하면 됩니다.

# release(1.1)에 대한 hotfix를 master에서 분기
$ git checkout -b hotfix-1.1.1 master

# 문제 해결 후 master 브랜치로 이동 후 병합
$ git checkout master
$ git merge --no-ff hotfix-1.1.1
# 병합한 커밋에 새로운 버전에 대한 태그 부여
$ git tag -a 1.1.1

# develop 브랜치에도 병합 후 삭제
$ git checkout develop
$ git merge --no-ff hotfix-1.1.1
$ git branch -d hotfix-1.1.1

브랜치 이름 규칙

< feature >
- 추천하는 형식은 "feature/기능"의 형태이며, 예를 들어 "feature/login" 등이 있습니다.
- 만약 Issue tracker id를 사용한다 하면, "feature/{issue-id}-{name}"으로 만들 수 있습니다.

< release >
- "release-버전"의 형식으로 사용하는 것을 추천합니다.

< hotfix >
- "hotfix-버전"의 형식으로 사용하는 것을 추천합니다.

References

• Gitflow Workflow
• A successful Git brancing model
• 브랜치의 종류
• 우린 Git-flow를 사용하고 있어요