Git Branch 전략

 

 

 

 

1. 개요

- 한 프로젝트를 개발하는데는 많은 개발자가 동원되어 코드를 수정하는 작업을 하는 것이 일반적이다.

혼자서 진행하는 개인프로젝트인 경우에는 master 브랜치에 수정 후 commit을 하거나 하나의 브랜치만 제작해 수정 후 삭제하더라도 크게 문제되는 부분은 없다. 하지만 개발자가 늘어날수록 브랜치간 충돌, 브랜치가 너무 많아지거나 의미를 파악하기 어려운 상황을 겪게 될 것이다. 따라서 프로젝트나 기업마다 브랜치 전략을 사용해 이를 해결한다.

 

 

 

2. Branch 전략 종류

• Github flow 
• Git flow
• GitLab flow

 

 

3. Github Flow

- 깃허브에서 만든 단순하고 간결한 브랜치 구조를 의미한다.

- Master 브랜치를 중심으로 운영

- 기능 추가, 버그 수정 등 간단한 브랜치를 생성해 작업하고 삭제하는 방식

- 배포과정이 자주 일어나는 환경에 용이하다.

 

방식 : 기능 추가, 버그 수정 작업을 위해 Master로 부터 새로운 브랜치 생성 후 작업을 진행한다. 이 후, 서버에 존재하는 해당 새로 생성된 브랜치에 push를 진행하고 Master 브랜치에서 PR을 진행한다. 이 후, 팀원간 토론 후 문제 없다면 내용을 Master에 합치는 작업을 진행한다. 그 전에 해당 새롭게 생성한 브랜치를 배포해보면서 미리 문제가 없는지 파악하고 없다면 Master에 합쳐 배포하는 것 또한 가능하다.

 

 

 

 

4. Git Flow 

- 5개의 브랜치를 운영

- 메인 브랜치로는 Master, Develop으로 설정하고 보조 브랜치는 feature, release, hotfix로 설정한다.

- 배포 주기가 긴, 즉, 이미 완성도가 높은 프로젝트에 용이하다.

 

방식 : Master 브랜치는 제품을 배포하기 위한 브랜치이고 Develop 브랜치는 개발자들의 개발이 이루어지는 브랜치를 의미한다.

이 때, Develop 브랜치에서 작업을 하고 새로운 버전과 같이 특정 버전의 작업이 완료되면 Master에 합치는 방식을 채택한다.

보조 브랜치는 feature(기능 구현), release(QA 진행), hotfix(버그 수정)가 있으며 작업 후 삭제된다는 점에서 메인 브랜치들과 차이점을 갖는다.

 

 

feature 브랜치 : Develop 브랜치의 새로운 버전을 위한 기능 구현

- develop 브랜치로 부터 파생

- 작업 완료 후 develop에 merge

- 하나의 새로운 기능 구현에 사용

- merge 이후에는 삭제

- merge 시 (--no-ff 사용 권장)

 

 

release 브랜치 : 새로운 버전 출시를 위한 QA 진행

- 다음 버전 출시를 위한 QA를 진행하는 브랜치

- 버그 수정, 버전 번호, 날짜 등의 메타 데이터를 준비, 기능 개발은 금지됨

- develop 브랜치로 부터 파생

- 작업 완료 후 develop 과 master에 merge

- merge 시 (--no-ff 사용 권장)

 

 

hotfix 브랜치 : 긴급한 문제 발생시 master로 부터 버그 수정

- 버그 발생시 빠른 대처를 위해 생성하는 브랜치

- master로 부터 파생

- 작업 완료 후 develop 과 master에 merge

- master로 merge 후에는 tag 명령을 통해 이전 버전보다 버전을 향상시킨다.