Git flow vs TBD(Trunk Based Development)

Vincent Driessen는 자신이 구상한 Git Flow에 회의적인 내용을 작성했다.

This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.

During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild, then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years. In that case, please read on.

To conclude, always remember that panaceas don't exist. Consider your own context. Don't be hating. Decide for yourself.

그가 지적한 대로 Git flow는 단일 버전 웹앱을 배포하기에는 너무 무겁다. dev 브랜치와 release 브랜치로 개발 주기와 QA 주기를 분리하면 수많은 MR과 체리픽, revert를 추적하는 비싼 비용을 지불해야 한다. 위 글에서 권장하는 Github flow는 git flow보다 가볍지만 여전히 장기 브랜치가 존재하므로 단일 Trunk에만 병합하는 TBD(Trunk Based Development)보다 여전히 무겁다.

TBD에서는 개발 주기와 QA 주기의 분리를 훨씬 적은 비용으로 달성한다. 모든 팀원은 단일 Trunk 브랜치에 매일 병합한다. Trunk 브랜치는 언제든 배포 가능해야하며, 프로덕션으로 갈 수 없는 기능은 feature flag로 닫을 수 있어야 한다.

이를 위해 신규 기능은 모두 하위 호환성을 유지해야 하고, 성숙하고 자동화된 CI/CD 및 테스트 커버리지가 필요하고, feature flag를 주기적으로 정리해야 한다. 그러나 압도적으로 빠른 개발 속도가 주는 이점이 비용을 상회한다.