[Git] Git 브랜치 전략 (git flow, github flow, gitlab flow)

Git 브랜치 전략 종류

git flow 전략

전통적으로 많이 사용되는 방식으로,

이 방법을 사용하면 master 브랜치는 항상 PROD와 동일한 상태를 바라볼 수 있다.

 

브랜치 종류

master	PROD 배포 버전을 관리하는 메인 브랜치
hotfix	PROD에서 발생하는 버그를 수정하기 위한 보조 브랜치
release	다음 버전 배포를 준비하는 보조 브랜치
develop	다음 버전 배포를 개발하는 메인 브랜치
feature	새로운 기능을 개발하는 보조 브랜치

 

문제점

git flow 전략에서 release는 하나만 존재한다.

develop에 완료된 기능을 release에 태우고, release에서 테스트를 진행한다.

따라서, 배포가 빈번하다면 배포 예정 작업(ex. v1.0.0)을 테스트할 수 없는 병목 현상이 일어날 수 있다.

(테스트 우선 순위에 있어서, v1.1.0이 먼저 테스트되어야 한다면, v1.0.0 테스트를 진행하다가 v1.1.0을 올려둔 후 다시 v1.0.0을 재배포하는 방법으로 우회할 수는 있을 것 같다.)

또한, 관리해야할 브랜치가 많아 신경써야할 부분이 늘기 때문에 git flow의 장점이 퇴색된다.

메인 브랜치가 두 개이기 때문에, 배포 후속 작업(master->develop 머지)을 통해 버전 동기화 과정이 필요하다.

 

github flow 전략

git flow 전략과는 다르게 하나의 메인 브랜치(develop 존재 X)로 release, hotfix 브랜치 또한 두지 않는다.

하나의 버전이 만들어졌으면, 배포될 수 있다는 개념이다.

단순하고 빠르기 때문에 에자일하게 배포가 가능하다.

주로 각 환경의 구분이 명확하지 않고 소규모인 프로젝트에 적합하다.

브랜치 종류

master	PROD 배포 버전을 관리하는 메인 브랜치
feature	새로운 기능을 개발하는 보조 브랜치

 

문제점

git flow와 비교했을 때, 테스트와 검증 절차가 부족하며 master 브랜치가 제대로 관리되지 않으면 위험도가 커진다.

 

gitlab flow 전략

github flow에서 배포, 릴리즈 등의 복잡한 이슈를 보완하기 위해 나온 전략이다.

얼핏보면 git flow와 동일해보이지만, git flow는 '개발'이 주요 목적이라면, gitlab flow는 '배포'가 중심이다.

그렇기 때문에 배포 전용 브랜치가 존재한다.

이때 배포 전용 브랜치(production)은 향상 프로젝트의 최신 버전 상태를 유지해야할 필요가 없다.

브랜치 종류

master	다음 버전 배포를 개발하는 메인 브랜치 (git flow의 develop과 동일한 역할)
production	PROD 배포 버전을 관리하는 메인 브랜치 (git flow의 master와 동일한 역할)
pre-production	master → production 브랜치 사이에 테스트를 진행하는 보조 브랜치 (git flow의 release와 동일한 역할)
feature	새로운 기능을 개발하는 보조 브랜치

 

gitlab flow 사용을 위한 11가지 규칙

1. master에 직접 커밋하기보다는 feature 브랜치를 사용한다.
2. master뿐 아니라 모든 커밋을 테스트 해야한다.
3. 모든 커밋에 대해 모든 테스트를 실행한다. (테스트가 5분이상 실행된느 경우 병렬로 실행할 수 있다.)
4. master로 합병 전, 코드 리뷰를 수행해야 한다.
5. 배포를 진행할 때 브랜치, 태그 기반으로 자동으로 진행되어야 한다.
6. 태그는 CI가 아닌 사용자가 설정한다.
7. 릴리즈는 태그를 기반으로 진행한다.
8. Push된 커밋은 리베이스를 하면 안된다.
9. 모든 것은 main에서 시작해서 main으로 합병된다.
10. main의 버그를 수정하고 branch에 릴리즈한다.
11. 커밋 메시지는 의도를 반영하여 잘 작성해야 한다.

 

💡 개인적인 생각
스프린트 주기로 배포 일정이 정기적이라면 git flow 전략도 괜찮았지만,
운영 업무로 인해 비정기적인 배포가 많다면 git flow로 관리하기에는 무리가 있는 것 같다. 
이런 경우는 github flow를 사용하거나, 안정성까지 고려한다면 gitlab flow를 이용하는게 좋은 것 같다.

 

Reference

Git 브랜치 전략 수립을 위한 전문가의 조언들 – 화해 블로그 | 기술 블로그

 

git flow; 환상과 현실 그 사이에 서비스

 

GitHub Flow vs Git Flow