[Git] 브랜치 전략

브랜치 전략에는 크게 두가지가 있다.

• Git flow
• Github flow

Git flow

Git Flow는 Vincent Driessen이 2010년에 제시한 Git 브랜치 전략이다. 

Git flow image

 

핵심 브랜치는 다음과 같다.

• mater branch: 운영환경에 배포되는 브랜치
• develop branch: 다음 배포를 위해 준비하는 브랜치 

이 외에도 feature, release, hotfix 브랜치가 존재하며 이는 핵심 브랜치를 보조하는 역할이다. 

Git flow 의 단점

• 너무 많은 브랜치
• 브랜치 병합 과정에서의 충돌
• 브랜치 관리 오버헤드

큰 규모의 프로젝트에서는 Git flow 가 적절할 수 있다. 이는 안정성을 높이고 구조화된 개발 프로세스로 이끌기 때문이다. 다만 빠르게 반복적으로 릴리즈 하는 조직에서는 Git flow 자체가 부담이 될 수 있다. 

Github flow 

Scott Chacon의 판단에 따라 만들어진 새로운 깃 관리 방식이다. trunk based 개발의 일종이며 아래와 같은 특징을 가지고 있다. 

• 새로운 브랜치는 항상 master 브랜치에서 생성
• 며칠 단위로 master에 merge
• feature, develop 브랜치 X
• 브랜치 이름이나 커밋메시지를 최대한 상세히 

Github flow image

Github flow 단점

아래와 같은 상황에선 며칠단위의 마스터 브랜치로의 merge가 어렵다. 

• 몇 주 or 몇 달의 개발기간이 필요한 경우
• 기능 자체가 다른 기능에 의존하는 경우

만들고자 하는 기능 A가 다른 기능 B에 의존적이라면, B 기능이 완료되기 전까지 A기능도 배포하기 어렵다. 

보완책 

피쳐토글(feature toggle) 

 

소프트웨어 개발에서 특정 기능을 동적으로 활성화 또는 비활성화할 수 있는 기술이다. 부분만 완성되었거나, 의존성 문제가 해결되지 않은 코드에 관해서 사용할 수 있다. 

• 전체 코드가 구현되지 않고 부분만 구현된 경우, 비활성화 상태로 코드를 먼저 배치 가능
• 의존해야 하는 부분이 완성되지 않은 경우, 비활성화 상태로 코드 배치 (후에 의존성 문제 해결 후, 코드 활성화)

[참고한 글]

https://tech.mfort.co.kr/blog/2022-08-05-trunk-based-development/

Git Flow에서 트렁크 기반 개발으로 나아가기 - 맘시터 기술블로그