TBD: Trunk Based Development

기존에는 git브랜치 전략으로 git-flow를 기반의 git 브랜치 전력으로 개발을 진행했다. 보편적으로 사용하는 방식이기에 협업을 할때 모두의 이해도가 높아서 사용하기 편리했다.

단점으로는 프로젝트를 진행하다보면 브랜치가 너무 많아지게 되며 브랜치를 관리하는데 어려움이 생겼다.

우리는 main, stage, dev와 각 feature 브랜치와 hotfix 브랜치를 만들어서 개발을 진행했었다. 하지만 팀 규모에 비해서 업데이트가 매우 잦은 프로젝트였고, Monorepo로 관리되는 프로젝트였기 떄문에 한명의 개발자가 관리하는 브랜치 수가 많아서 버전 업데이트를 할때 각 브랜치를 병합시킬때 혼동이 생기는 문제가 있었다.

이미 개발한 브랜치를 main까지 올렸다가 제거했다가 나중에 다시 추가하는 경우도 있었고, 그 과정에서 병합 출동이 빈번했다.

예를 들자면 A라는 feature 브랜치가 main에 올라가 있는데, B라는 기능을 main에 올리면서 잠시 A기능을 main에 제거 했다가, C라는 기능을 추가하고 다시 A기능을 추가하는 경우가 있다. 해당 코드는 한 페이지안에 들어 있는 기능이 였기에, 브랜치로만으로 단순히 merge하고 rebase하기에는 여러 충돌을 만들었다.

이러한 문제들을 격고 나서 TBD를 도입하기로 했다.

TBD는 Trunk Based Development의 약자로, git-flow와는 다르게 main 브랜치를 중심으로 개발을 진행하는 방식이다. 모든 개발을 stage 브랜치에서 진행하고 실제로 main에 병합하는 방식을 선택했다.

TBD는 하나의 브랜치로 개발을 진행하는 방식이였는데, QA를 위해서 2개의 브랜치를 사용했다.

이러한 방식을 선택하게 되면 문제가 기존의 feature브랜치처럼 기능을 미리 개발하고 나중에 추가하는 방식을 사용할 수는 없다.

이 방식을 도입하고 좋았던 점으로, 오래된 기능을 삭제하고, 브랜치또한 제거했던 기능을 갑자기 다시 추가하는 경우가 있었는데 위와 같이 코드를 삭제된 코드를 관리하기 쉬워졌다.



Reference

[1] "우린 Git-flow를 사용하고 있어요" 우아한기술블로그 "2017.10.30" https://techblog.woowahan.com/2553/
[2] trunkbaseddevelopment https://trunkbaseddevelopment.com/