Git Flow는 표준 Git 워크플로가 아닙니다.

Hoyoung Jung·2023년 12월 27일

안녕하세요? 소프트웨어 교육기업 코드스쿼드에서 백엔드를 담당하고 있는 호눅스입니다.
저는 2010년에 사내 Linux 커널 관리를 위해 처음 Git을 사용하기 시작한 후 지금까지 잘 사용하고 있는데요.
오늘은 간단히 Git의 워크플로에 대해 써 보려고 합니다.

처음 Git이 등장하던 시절 많은 IT 회사들은 버전관리를 잘 하지 않았습니다.
그리고 Git 이 아닌 다른 VCS를 사용하는 곳도 많았는데요. CVS와 svn이 꽤 많이 사용되고 있었던 것 같습니다.

Git은 다른 VCS와 다르게 DVCS - 분산 버전 관리 시스템 - 이었고, 강력한 브랜칭 기능을 가지고 있습니다.
그래서 이들을 잘 활용해야 하는데, 이 점이 오히려 기존의 VCS 사용자에게는 어렵게 다가오기도 했습니다.

DVCS의 특징과 브랜칭을 잘 사용하면서 git을 사용해 협업하는 방법, 이것이 Git 워크플로라고 할 수 있습니다. 다양한 방법이 있는데, 대중적으로 가장 많이 사용하는 것은 Git Flow입니다.

우린 Git-flow를 사용하고 있어요 글을 본 많은 취준생 분들이 팀 프로젝트를 할 때 Git Flow로 협업을 하기로 했다고 하더군요.
그 외에 Git flow 치트시트 도 있구요. Git flow를 소개한 글들은 정말 많습니다.
하지만 정작 Git flow를 만든 Vincent Driessen은 Git flow 10년 회고 글을 통해 우려를 표하기도 했습니다.

이 모델은 지금으로부터 10년 전인 2010년에 고안된 것으로, Git 자체가 등장한 지 얼마 되지 않은 시점입니다.
이 글에서 설명하는 브랜칭 모델인 깃플로는 10년 동안 많은 소프트웨어 팀에서 큰 인기를 끌면서 사람들이 일종의 표준처럼 취급하기 시작했지만, 안타깝게도 도그마나 만병통치약처럼 여겨지기도 했습니다.

지난 10년 동안 Git 자체는 전 세계를 강타했으며, 적어도 제 필터 버블에서는 Git으로 개발되는 가장 인기 있는 소프트웨어 유형이 웹 앱으로 더 많이 이동하고 있습니다.
웹 앱은 일반적으로 롤백되지 않고 지속적으로 제공되며, 야생에서 실행되는 소프트웨어의 여러 버전을 지원할 필요가 없습니다.

10년 전 블로그 게시물을 작성할 때 염두에 두었던 소프트웨어의 종류가 아닙니다. 팀에서 소프트웨어의 지속적 배포를 수행하는 경우, 팀에 깃플로우를 무리하게 도입하는 대신 훨씬 더 간단한 워크플로(예: GitHub 플로우)를 채택하는 것이 좋습니다.

하지만 명시적으로 버전이 지정된 소프트웨어를 빌드하거나 여러 버전의 소프트웨어를 지원해야 하는 경우에는 지난 10년 동안 사람들에게 그랬던 것처럼 깃플로우가 여전히 팀에 적합할 수 있습니다. 그렇다면 계속 읽어보세요.

결론적으로, 만병통치약은 존재하지 않는다는 사실을 항상 기억하세요. 자신의 상황을 고려하세요. 미워하지 마세요. 스스로 결정하세요.

Translated with DeepL.com (free version)

결국 Git-flow는 "자주 롤백되면서 여러 가지 버전을 동시에 배포할 필요가 있는 소프트웨어" 에 맞춰져 있는 셈입니다. 그렇지 않은 경우라면 불필요하게 복잡한 워크플로를 사용하고 있을 가능성이 높습니다. 불필요한 복잡성은 생산성을 낮추는 요인이 될 수도 있겠죠. 아틀라시안의 블로그 글에는 심지어 main 브랜치만 만들고 브랜치를 안 만드는 것도 충분히 사용할 수 있는 브랜칭 전략이라고 이야기합니다.

몇 개의 참고 링크를 적고 글을 마무리하려 합니다. 팀프로젝트에서 어떤 워크플로, 혹은 브랜칭 전략을 사용할지, 그리고 이를 어떻게 팀에 맞게 변형할지 결정하는 것은 온전히 여러분의 몫입니다. 다만 합리적인 선택의 이유, 결정의 근거가 있었으면 좋겠습니다.