[Git] trunk base development

#Git

trunk base develeopment는 Git branch 관리 전략 중 하나다.
git flow와 정반대의 특성을 가진다.

쉽게 말해서, 개발 브랜치를 쓸데없이 파편화하지 말고 단일 브랜치(master 등)로만 잡고 작은 feature 단위 merge만을 빠르게 하면서 이어나가라는 것이다.

여기서의 핵심 논리는 브랜치를 여러개 두지 말라는 것이 아니다. 단지 "수명이 긴" 브랜치를 여러개 두지 말라는 것이다.

다중 브랜치 관리의 문제 (with Git Flow)

git flow 전략에서는 다중 브랜치 기반으로 작업 유연성과 독립성을 가져가는 것을 꽤나 권장하는 편이다.
예를 들면 "v1.0.2" 배포나 "feature 결제시스템 구현" 같은 큰 단위로도 브랜치를 만들 수 있다.

이렇게 큰 기능 단위로 브랜치를 만들어서 작업을 하다보면, 하나의 브랜치 작업이 몇주나 한달이 걸리더라도 이상하진 않다.

논리적으로 큰 문제는 없는 방법론이지만, 실제로 운영을 하다보면 어려움이 좀 많이 생길 수 있다.

가장 큰 단점은 충돌과 지연 문제다. 코드가 빠르게 변화할수록 메인 브랜치에는 변경사항이 누적될텐데, 양쪽 브랜치가 오랫동안 유지된 채로 유지되면 merge할때 충돌이 매우 극심하게 발생할 수 있다.

conflict 스트레스도 스트레스지만 진짜 문제는 충돌이 많이 발생할수록 실수를 할 가능성이 늘어나고, 다른 팀원들과의 혼선이 발생할 가능성도 늘어난다는 것이다.

그래서 trunk base에서는 개발 작업 브랜치는 되도록 단일 브랜치로만 잡고, 빠르게 작은 작업 단위로 merge를 하는 것을 권장한다.

그래야 충돌 문제도 훨씬 적고, 다른 팀원들과의 컨텍스트 공유 등도 빠르게 이루어질 수 있기 때문이다.

하지만 trunk base 방식도 단점이 없는 것은 아니다.
대부분의 기술들이 그렇듯 trade-off가 있고, trunk base와 git flow가 적합한 용처가 다를 뿐이다.

개발 조직이 그렇게 크지 않고, 동시 버전 지원 없이 계속해서 최신화해도 좋은 시스템이라면 trunk base가 가장 효율적일 것이다.
일반적인 응용프로그램들은 trunk base를 우선으로 고려할만하다.

하지만 단일 개발 조직이 매우 크거나, 버전별 동시 지원이 필요한 경우에는 git flow가 적합하다.

예를 들면 컴파일러 같은 경우에는 구버전들에 대해서도 지속적인 기능 개선/패치가 들어가야 한다.
이 경우에는 당연히 버전별로 수명이 긴 브랜치를 유지하면서 작업하는 것이 합리적이다.

이런 식으로 말이다.
피곤하긴 하지만 어쩔 수 없다. 이렇게 해야 한다.