각 브랜치 전략 비교 (git flow, github flow, gitlab flow, TBD)

브랜치 전략?

여러 개발자가 1개의 저장소를 사용하는 환경에서 효과적으로 활용하기 위해 나온 개념. 브랜치 생성, 병합등의 git 구조를 활용해 효율적으로 소스를 관리하고, 협업을 진행할 수 있다.

git flow

2010년에에 Vincent Driessen란 사람이 블로그에 올린 글로 인해 널리 퍼지기 시작한 방법. 총 5개의 브런치로 구성하고 있으며 master와 develop 브랜치가 중심이 된다. 두 개를 이용하여 릴리즈와 운영환경에 배포할 수 있는 환경을 갖추는 게 핵심.

master라는 mainline을 중심으로 가지가 뻗어져 나간다.

master : 운영환경에 배포하는 용도로 쓰기 위한 브랜치.

develop : 개발용 브랜치로, 단위 개발을 위한 feature브랜치가 여기서 뻗어져 나오며, 개발된 기능을 develop에서 주로 merge하고 있다.

release : 배포를 위해 master 브랜치로 보내기 전, QA와 테스트를 위해 만들어진 브랜치.

hotfix : 운영 환경에서 치명적인 버그가 발견되었을 시 긴급 수정하기 위해 만들어진 브랜치.

명확한 릴리즈 기간과 주기적인 버전이 정해진 프로젝트에 적합.

릴리즈 버전을 위해 release 브랜치를 따로 관리하기 때문에, 여러 버전을 관리해야 할 필요가 있을 때 적합하다.

github flow

시간이 지나면서 웹 기술도 많은 발전을 이루었다. html이나 깨작거리던 웹은 이젠 대부분의 기술에 응용되고 있으며, 프론트엔드와 백엔드라는 명확한 경계선으로 나뉠 수 있게 되었다.

git flow를 제안한 vincent driessen은 10년이 지난 2020년. git flow는 프론트와 백엔드가 명확하게 나누어진 웹 앱 개발에 적합하지 않는 전략이라 설명했다.

기술이 고도화 되면서 브랜치 전략도 점점 고도화되기 시작했다. CI/CD를 중심으로 하는 github flow는 git flow가 github에서 동작하기엔 너무 복잡하다고 생각해 생긴 전략이다.

흐름은 단순하다. master 브랜치에 대한 명확한 role을 정의 한뒤에 나머지 브랜치들에는 관여하지 않는다. 그리고 pull request를 사용하도록 권장하고 있다.

특징으로는 master 브랜치에서만 브랜치가 뻗어나갈 수 있으며, master 브랜치는 어떤 때든 배포 가능하도록 최신의 stable한 상태를 유지해야한다는 점이다.

또한 local branch에 지속적으로 커밋한 뒤에, 원격 브랜치에 수시로 push 하여 내 원격 브랜치에 일어난 일들을 다른 사람들도 확인할 수 있도록 해야 한다.

따라서 feature 브랜치나 develop 브랜치가 따로 존재하지 않으며, merge가 필요할 시 pr을 통한 엄격한 코드 리뷰를 통해 master에 즉시 배포될 수 있도록 해야한다.

장점으로는

• 브랜치 전략이 단순하다
• pr을 통한 자연스러운 코드 리뷰
• github에 최적화
• Ci/CD를 통한 자동화

단점으로는

• 운영에 바로 배포되기 때문에 엄격한 CI/CD role이 필요
• 배포 기간이 길어지는 작업이 있으면 작업이 힘들어진다.
• 다른 기능에 의존하는 기능을 만들 시, 복잡해진다.
•  

gitlab flow

git flow와 github flow의 중간에 있는 브랜치 전략.

gitlab에서는 4가지의 전략을 제시했지만, 가장 많이 사용하는 건

Environment branches with gitlab flow 전략이다.

오늘은 Environment branches 전략만 알아보도록 하자.

Environment branches with gitlab flow

master와 feature, production과 pre-production 4개로 이루어져있다.

feature

모든 기능 구현이 시작되는 브랜치이며, master브랜치에 분기된다.

master

gitlab flow의 master는 git flow의 deveop과 동일하다. master에서 feature 브랜치에서 병합된 기능에 대한 테스트를 진행하고 이후, 문제가 없는 게 확인 된다면 production 브랜치로 머지한다.

production

git flow의 master 브랜치와 동일. 테스트가 끝난 후 운영 환경에 배포하기 위한 브랜치.

pre-production

master와 production 사이에 있는 브랜치. 변경 사항을 운영에 배포하기 전 테스트 할수 있는 브랜치로, 주로 staging 단계에서 진행하는 테스트 및 qa를 pre-production 브랜치에서 진행할 수 있다.

gitlab은 최근에 gitlab flow 전략을 최신으로 갱신했다. 하지만 이 전략은 말 그대로 gitlab의 CI/CD에 특화되어 있으니 패스.

Combine GitLab Flow and GitLab Duo for a workflow powerhouse

Combine GitLab Flow and GitLab Duo for a workflow powerhouse

tbd(trunked base development)

트렁크 기반 개발은 git flow의 대안으로 사용되는 브랜치 전략이다. 현재 google과 facebook에서 시행하는 브랜치 전략으로 알려져 있으며, **trunkbaseddevelopment.com**에서는 트렁크 기반 개발을 아래와 같이 한 문단으로 설명한다.

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.
일종의 코드 관리 브랜칭 모델이며, 여기서는 개발자들이 ‘트렁크’라고 불리는 단일 브랜치 위에서 협력하고, 오래 유지되는 개발 브랜치를 만들게 하는 압력에 저항하기 위해 위해 설명된 테크닉을 사용합니다. 그러므로 그들은 머지 헬을 피하고, 빌드를 깨트리지 않고, 영원히 행복하게 살아갑니다.

브랜치 전략은 간단하다.

trunk(or master) 브랜치 하나만 운영하며, 신규 기능들은 곧바로 trunk에 커밋하거나, 며칠내에 trunk에 머지할 피쳐 브랜치에서 작업한다.

trunk 브랜치에 코드가 머지되었다면 자동화된 CI를 통해 브랜치에 대한 테스트 및 통합 과정이 통과되는 지 확인한다. 이후 문제점이 발견되지 않으면 운영 환경에 배포된다.

그렇기에 배포하기전 테스트 코드 커버리지를 넓힘으로써, trunk에 반영하기 전 일어날 수 있는 에러를 최대한 파악하고 대비해야만 한다.

아래는 tbd에서 정한 규칙들이다.

1.페어 프로그래밍

페어 프로그래밍(Pair Programming)이란 두 명의 개발자가 한 곳에서 한 명은 코드를 작성하고 한 명은 각 코드행을 검토하는 방식이다. 이 둘 사이의 역할은 언제든지 뒤바뀔 수 있으며, 작성 중인 코드는 실시간으로 검토된다. 추후 PR 요청이 따로 필요하지 않아 이는 결국 생산성 향상에 기여하게 된다. 뿐만 아니라 더 높은 품질, 코딩 스타일 통일, 지식 공유, 문제 해결에 대한 해결책을 같이 찾음 등의 이점이 있다.

2.신뢰할 수 있는 빌드 환경

코드 베이스가 항상 릴리즈가 가능한 상태임을 확신할 수 있어야 한다. 그러기 위해서는 충분한 자동 테스트가 병행되어야 하며, 효과적이고 우수한 테스트 전략 필요하다.

3.소규모 배치 개발

팀이 프로덕션 release를 더 자주 할 수 있게 분업을 수행하며, 작업이 며칠이 아닌 몇 시간 안에 완료할 수 있는 소규모 변경사항으로 쪼갠다.

4.빠른 빌드.

빌드 및 테스트 프로세스는 몇 분 내에 실행되어야 한다. 만약 그렇게 할 수 없다면 시스템 아키텍처에 개선이 필요하다는 것을 의미한다.

5. Branch by abstraction 또는 feature Flag(Feature Toggle)을 사용하여 작업이 완료되지 않는 부분을 숨겨야 한다.

위 링크 참조.

TBD는 브랜치가 존재하지 않는다기 보단 필요시 짧은 수명의 브랜치만을 사용하는 전략이다. 하지만 결국 모든 개발자는 항상 프로덕션 환경에서 실행되는 최신 버전의 코드를 가지게 된다.

github flow와 유사하지만 차이점이 있다면 tbd에서 중시하는 간단함이다. 프로세스의 간단함과, 작은 단위의개발 기간로 잦은 배포가 이루어지게 된다.

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

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

 

*TBD와 git flow의 가장 큰 차이.

git flow는 검증 환경(staging)과 운영 환경(production)이 명확하게 구분되어 있다.

TBD는 검증 환경을 거치지 않고 곧바로 운영 환경에 배포한다.

git flow는 큰 덩어리의 기능을 검증 후 한번에 배포.

TBD는 작은 기능 여러개를 최소한으로 검증하고 배포.