[git] git flow - 브랜치 전략

 

Git 브랜치 전략

Git 브랜치 전략은 프로젝트의 git 브랜치를 효과적으로 관리하기 위한 워크플로우를 의미한다. 직접 브랜치 전략을 수립해도 되지만, 이미 많은 모범 사례들이 존재한다. 그 모범사례 중 유명한 Git Flow에 대해 알아보자.

 

Git Flow

Git Flow는 Vincent Driessen이 2010년에 올린 'A successful Git branching model'이란 블로그 글이 인기를 끌며 대중화된 브랜치 전략이라고 한다.

Git Flow는 크게 Main / Develop / Supporting 브랜치로 구분하여 브랜치를 관리한다. 이때 Supporting 브랜치는 다시 Feature / Release / Hotfix 브랜치로 나뉜다.

Main 브랜치와 Develop 브랜치는 개발 프로세스 전반에 걸쳐 항상 유지되는 브랜치이고, Supporting 브랜치는 필요할 때마다 생성되고 역할을 다하면 삭제되는 브랜치이다. Supporting 브랜치 덕분에 팀이 병렬적으로 일할 수 있게 된다.

Git Flow

 

Main(Master) 브랜치

출시 가능한 프로덕션 코드를 모아두는 브랜치. Main 브랜치는 프로젝트 시작 시 생성되고, 개발 프로세스 전반에 걸쳐 유지된다. 배포된 각 버전을 Tag를 이용해 표시해둔다.

 

Develop 브랜치

다음 버전 개발을 위한 코드를 모아두는 브랜치. 개발이 완료되면 Main 브랜치로 머지된다.

 

Feature 브랜치

하나의 기능을 개발하기 위한 브랜치. Develop 브랜치에서 생성하며, 기능 개발이 완료되면 다시 Develop 브랜치로 머지된다. 머지할 때 주의점은 Fast-foward로 머지하지 않고 Merge Commit을 생성하여 머지해주어야 한다는 점이다. 이렇게 해야 히스토리가 특정 기능 단위로 묶여서 기록된다. 네이밍은 feature/branch-name 과 같은 형태로 생성한다.

 

Release 브랜치

소프트웨어 배포를 준비하기 위한 브랜치. Develop 브랜치에서 생성하며, 버전 이름 등의 소소한 데이터를 수정하거나 배포 전 사소한 버그를 수정하기 위해 사용된다. 배포 준비가 완료되면 Main과 Develop 브랜치에 둘 다 머지한다. 이때 Main 브랜치에는 태그를 이용하여 버전을 표시해준다.

Release 브랜치를 따로 운용함으로써 배포 업무와 관련 없는 팀원들은 병렬적으로 Feature 브랜치에서 이어서 기능을 개발할 수 있게 된다. 네이밍은 release/v1.1 과 같은 형태로 생성한다.

 

Hotfix 브랜치

이미 배포된 버전에 문제가 발생했다면, Hotfix 브랜치를 사용하여 문제를 해결한다. Main 브랜치에서 생성하며, 문제 해결이 완료되면 Main과 Develop 브랜치에 둘 다 머지한다.

Release 브랜치와 마찬가지로 Hotfix 브랜치를 따로 운용함으로써, 핫픽스 업무와 관련 없는 팀은 병렬적으로 기능 개발을 할 수 있다. 네이밍은 hotfix/v1.0.1 과같은 형태로 생성한다.