title: "GitOps 시대의 git branching 모델 : TBD(Trunk Based Development)"
description: "TBD(Trunk Based Development) 등장 배경, 개념, gitflow와의 비교"
cleanUrl: /sw-engineer/trunk-based-development
ogImage: "<https://oopy.lazyrockets.com/api/v2/notion/image?src=https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fcbf44bad-2205-435f-9e89-4bc926c4dafc%2FUntitled.png&blockId=5d8fba87-4301-45ed-8cbe-7a324b277d85>"
floatFirstTOC: right

들어가며

명색이 ‘NEXT’란 명칭이 들어간 프로젝트 중에 행여나 하는 마음으로 찾아본 git branching 전략 트랜드… 아니나 다를까 git branching 모델 역시 NEXT가 있었네. 이름하야 TBD(Trunk Based Development; To Be Determined가 아니고…). 근간의 CI/CD는 DevOps를 넘어서 GitOps를 추구하고. git 관리의 핵심 중 하나가 branching 전략인데 이걸 그냥 넘어갈 수는 없서리.

TBD(Trunk Based Development) 이전에는

그 유명한 gitflow가 있고. 모르긴 몰라도 gitflow는 현 시점에서조차 가장 많이 사용되는 branching 모델이 아닐까 싶은데. 링크는 (아마도) gitflow가 처음 소개된 blog. 지금 보니 무려 13년전에 쓰였네. 아래 그림은 해당 blog에서 발쵀한 gitflow의 요약이다.

Untitled

gitflow의 핵심을 요약하자면 다음과 같다.

master / develop 두 개의 무한 수명 branch. develop은 daily build가 수행되는 branch이며, develop에서 안정점을 찾으면 배포와 함께 안정적 버전을 뜻하는 master로 merge된다.
상기 과정을 위해 상당히 오랜 시간 유지되는 feature를 비롯해, release, hotfix 등의 조력 branch가 상시 동원된다.

TBD 등장

‘등장’… 이렇게 이야기하면 마치 근간에 나온 물건으로 보이겠지만, 개념 자체는 소프트웨어 개발 초창기부터 있었고, TBD란 말은 2010년대 초에 Paul Hammant란 소프트웨어 컨설턴트에 의해 유명해졌다고(chatGPT 왈). TBD로 꽤 유명해보이는 사이트 주인장이다(무려 구글 클라우드 센터에서 이를 참조하라 가이드 중. 그의 github도 참조. 얼굴 볼 수 있음)

다음은 위 사이트에서 발쵀한 TBD 그림이다(Scaled Trunk-Based Development).

Untitled

간단히 핵심만 간추리자면 다음과 같다.

무한 수명 branch는 trunk (또는 master 또는 main ) 말곤 없다(release 는 배포 직전에만… 단명(short live)한다.
develop 등의 안정화를 중간 branch를 두지 않으며, release를 제외한 여타 branch는 ‘바로바로’ trunk로 merge된다.

이제 왜 새로운 개념이 아니라는지 바로 이해된다. 이건 그냥, gitflow등의 본격적 branching 모델을 채용하기 전에 일반적으로 쓰이는, ad-hoc한 느낌으로 사용하는 git 사용 모델과 별반 차이가 없다.

하지만 TBD가 강조하는 practice의 특징을 보면 gitflow와 차이가 명확히 드러나며 비교우위점 또한 마찬가지이다.