처음으로 Git을 배우고 Branch와 merge를 하면서, 나는 항상 조금을 불안함을 가진다.
'내가 지금 옳은 브랜치에 merge를 하고 있는 것이 맞는지,' 그리고 '이 브랜치에서 새로운 브랜치를 생성해도 되는지'.
다행스럽게도 이러한 혼란은 나만 겪는 것은 아닌지, 브랜치를 효과적으로 관리하기 위한 여러 전략들이 존재한다.
다양한 전략들 중, 가장 유명한 사례 중 하나인 Git Flow에 대해 '코드잇 스프린트 2주차 페이퍼 과제'를 기회로 알아보게 되었다.
Git Flow는 크게 3가지 브랜치로 분류해 관리하고, Supporting 브랜치는 다시 3개의 하위 브랜치로 나뉜다.
- Main Branch
- Develop Branch
- Supporting Branch
- Feature Branch
- Release Branch
- Hotfix Branch
개발 프로세스 전반에 걸쳐 항상 유지되는 브랜치:
Main Branch
Develop Branch
필요에 의해 생성/삭제를 반복하는 브랜치:
Supporting Branch
1. Main Branch
출시 가능한 프로덕션 코드를 모아두는 브랜치
프로젝트 시작 시 생성되는 브랜치로, 개발 프로세스 전반에 걸쳐 유지된다. 배포된 각 버전을 Tag를 이용해 표시한다.
2. Develop Branch
다음 버전 개발을 위한 코드를 모아두는 브랜치
개발이 완료되면 Main Branch로 머지한다.
3. Supporting Branch
A. Feature Branch
하나의 기능을 개발하기 위한 브랜치
-
Develop Branch에서 생성해서, 개발이 완료되면 다시 Develop Branch로 머지한다.
-
머지할 때는 커밋 히스토리를 특정 기능 단위로 묶기 위해 Merge Commit으로 머지를 해주어야 한다.
-
feature/branch-name같은 형태의 네이밍을 사용한다.
B. Release Branch
소프트웨어 배포를 준비하기 위한 브랜치
- Develop Branch에서 생성해서, 배포 준비가 완료되면 Main Branch와 Develop Branch에 머지한다.
- Main Branch에는 tag를 이용해 버전을 표기
- 배포 전 버그를 수정하는 등, 배포 이전 절차를 해당 브랜치에서 처리한다.
release/v1.1같은 형태의 네이밍을 사용한다.
C. Hotfix Branch
배포 이후 발생한 문제를 해결하기 위한 브랜치
- Main Branch에서 생성해서, 코드 수정이 끝나면 Main Branch와 Develop Branch에 머지한다.
hotfix/v1.0.1같은 형태의 네이밍을 사용한다.
Release Branch와 Hotfix Branch를 사용하므로서 해당 작업을 수행하지 않는 다른 팀원들이 병렬적으로 Feature Branch에서 다른 기능을 개발할 수 있는 이점을 가진다.
