"Patterns always have two parts: the how and the when." 2013년에 합류한 팀은 git flow를 사용하고 있었다. 1년 정도 쓰면서 얻은 것은 고통뿐

"Patterns always have two parts: the how and the when." 2013년에 합류한 팀은 git flow를 사용하고 있었다. 1년 정도 쓰면서 얻은 것은 고통뿐이었고 이직 후 내다버렸다. 그 때 git flow를 비판하면 투덜이 스머프나 이단자 취급을 받았다. 세상은 git flow를 브랜칭 약속의 땅으로 여겼으니까. Vincent Driessen의 브랜칭 모델 소개글은 눈부시게 아름다운 그림과 함께 소프트웨어 개발 협업 과정의 모든 문제를 해결해 줄 거란 예언을 담고 있었다. 안타깝게도 그건 단지 읽는 이들의 관점이었을 뿐 Vincent Driessen은 그저 한가지 the how를 소개한 것이었다. 이렇게 예언서를 읽은 많은 개발팀들은 자신들의 환경은 생각하지 않고 너도나도 git flow를 도입했다. Git을 쓰면서 develop 브랜치가 없는 건 상상할 수 없는 일이었다. 하지만 인터넷 서비스를 개발하고 CI를 사용하려 한다면 git flow는 안티패턴이다. Vincent Driessen의 글을 제대로 이해했다면 눈치챌 수 있고, 그렇지 않더라도 직접 develop 브랜치를 운영해보면 이 암세포가 CI에 얼마나 고통을 주는지 느낄 수 있다. Vincent Driessen은 브랜칭 모델 소개 10년 후인 2020년에, git flow는 과거 다중 버전 관리가 필요한 소프트웨어에 유용한 것이었으며 지속적으로 배달되는 소프트웨어에는 git flow가 적합하지 않다고 밝혔다. 시대가 변해 세상엔 전자에 비해 후자가 지배적으로 많아졌다. 그러면 그동안, 그리고 아직도 CI, CD, DevOps 등을 추구한다는 팀이 git flow를 사용하고 심지어 그것을 블로그 등을 통해 뽐내는 이유는 뭘까? 멋진 the how에 홀려 the when은 까맣게 잊어버렸고 고통을 고통인지 모르고 있다는 것이 내 뇌피셜이다. 예언자 Vincent Driessen이 예언을 철회했지만 광신도들에겐 예언자가 누군지 조차 관심대상이 아니다. 비효율과 스트레스는 상관없다. 멋지고 화려한 git flow를 사용하고 있다는 사실이 가장 중요하다.