[Git] 브랜치 전략 - Git Flow

 

/* 브랜치 전략 */

협업 프로젝트를 하기 위해서는 브랜치 전략을 설정하는 것이 매우 중요하다. 충돌을 조기에 발견하고 해결할 수도 있고 버전 관리, 롤백 같은 작업을 편리하게 한다.

 

/* Git Flow */

Git Flow 브랜치 전략은 릴리즈 버전 관리를 간편화하는데 용이하다.

 

위의 그림을 보면 5가지의 브랜치가 보인다. (회사마다 상이할 수 있음)

feature, develop, release, hotfixes, master

 

/* master (main) 브랜치 */

 

master 브랜치는 릴리즈 될 프로덕션을 포함하는 브랜치이다.

그림의 Tag (번호)는 버전 정보이다.

master 브랜치는 안정화된 기능에 대해서만 배포가 이루어져야 한다.

/* develop 브랜치 */

 

말 그대로 개발을 위한 브랜치이다. 

develop 브랜치에서 기능 변경이나 추가, 삭제가 이루어져서 배포 준비 단계에 다다르면

master 브랜치로 향하는 것이 아니라 release 브랜치를 거쳐야 한다.

/* release 브랜치 */

 

release 브랜치 (초록색)는 develop 브랜치에서 보내진 코드들을 담당한다.

develop 브랜치에서 에러나 오류를 해결했다고 해도 남아있는 버그들을 잡기 위해 release 브랜치가 존재한다.

물론 버그가 고쳐지만 develop 브랜치에도 반영을 해야 한다.

 

release 브랜치는 develop 브랜치와 다르게 버그 픽스만이 이루어진다 (기능 개발 X)

 

release 브랜치에서 버그 픽스가 완료가 되면 master 브랜치로 병합한다. (tag 명시와 함께)

이때 병합 전략은 전의 게시글에서 merge 전략 중 하나를 수행한다.

/* feature 브랜치 */

 

위의 그림을 보면 feature 브랜치가 여러개 임을 확인 할 수 있다 (feature branch'es')

즉 feature 브랜치 하나는 기능 하나를 담당한다.

만약 develop 브랜치에서 기능 여러개를 동시에 담당하면 기능 하나를 개발해도 나머지 기능이 개발이 완료가 안되어서 release 브랜치로 못보내는 상황이 발생한다. 이를 위해 feature 브랜치가 존재한다.

/* hotfixes 브랜치 */

 

master 브랜치에서도 버그가 발생할 수 있다. 기존에는 develop 브랜치와 release 브랜치에서 버그 픽스가 이루어져있지만

빨리 해결해야하는 버그 픽스를 위해서는 hotfixes 브랜치가 필요하다. (빠른 해결을 위해)

그러면 hotfixes 에서 버그를 해결하고 master 브랜치로 바로 병합을 할 때 버전은 1.1 -> 1.2 와 같이 소수점 버전 업데이트로 이름을 짓는다.

 

/* Git Flow 장단점 */

- 장점

• 개발 인력이 많을 때 효율적
• 핫픽스 처리 용이
• 버전 관리에 용이

- 단점

• 복잡하다 (여러 브랜치 사용)
• merge가 자주 발생하기에 충돌에 조심해야 함