Development

Git flow, 왜 적용했나요?

2023년 01월 28일

프로젝트를 운영하다 보면 자연스럽게 브랜치 전략에 대한 고민을 하게 된다.
대부분의 프로젝트에서 VCS(Version Control System)로 Git을 사용하고 있고, 협업을 위해 각자 나름의 브랜치 관리 전략을 두고 있을 거다.

브랜치 전략 중 가장 대중적인 방식은 Git-flow다. 한 번쯤은 들어봤을 테고, 구조도 어느 정도는 익숙할 거라 생각한다. 실제로 사용해보면 꽤 잘 정리된 전략처럼 느껴질 때도 있고, 반대로 어딘가 불편하다는 생각이 들 때도 있다.

그래서 자연스럽게 이런 질문이 따라왔다.

Git-flow 말고 다른 브랜치 전략에 대해서도 알고 있을까?
알고 있다면, 왜 Git-flow를 선택했을까?
혹은 왜 선택하지 않았을까?

이 글은 그런 사소한 불만에서 시작한 고민을 정리한 기록이다.

Git-flow, 다시 보기

먼저 Git-flow가 무엇인지부터 다시 짚어본다.

Git-flow는 Vincent Driessen이 처음 제안한 Git 브랜치 모델이다.
main, develop, feature, release, hotfix 같은 브랜치를 두고, 각 브랜치에 명확한 역할을 부여하는 방식이다. Git을 사용하는 워크플로우의 정석처럼 소개되곤 한다.

다만 이 모델은 2010년에 제안된 방식이다. 오랫동안 많은 팀에서 사용된 것도 사실이지만, 모든 상황에 잘 맞는 전략이라고 보기는 어렵다. 이 점에 대해 Vincent Driessen 본인도 2020년에 다시 의견을 남겼다.

This model was conceived in 2010, now more than 10 years ago...
If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow)...
To conclude, always remember that panaceas don't exist. Consider your own context.

요지를 정리하면 다음과 같다.

Git-flow는 제안된 지 오래됐고, 표준처럼 쓰이고 있다.
웹 애플리케이션은 보통 롤백 없이 지속적으로 배포된다.
이런 환경에서는 Git-flow가 과할 수 있다.
지속적 배포 환경이라면 GitHub-flow 같은 단순한 워크플로우가 더 적합할 수 있다.
반대로 명확한 버전 관리가 필요하다면 Git-flow는 여전히 유효하다.
만병통치약은 없다. 결국 상황이 중요하다.

이 내용을 다시 읽으면서 자연스럽게 이런 질문이 들었다.

“우리는 지금 Git-flow가 잘 맞는 상황일까?”

단순히 브랜치를 어떻게 쓰느냐의 문제가 아니라,
지금 우리 팀과 서비스에 맞는 전략인지 다시 고민해볼 필요가 있지 않을까라는 생각으로 이어졌다.

Git-flow에 대한 의문들

실제로 Git-flow에 대해 비슷한 의문을 제기한 글들이 꽤 많다.
조사하면서 참고했던 레퍼런스들은 아래와 같다.

이 글들을 읽고 나면 공통적으로 나오는 쟁점이 하나 있다.

develop 브랜치는 정말 필요한가?

물론 Git-flow에 비판적인 글들 위주로 보다 보니 어느 정도 편향은 있을 수 있다.
그럼에도 불구하고 논의의 중심이 develop 브랜치에 있다는 점은 분명해 보였다.

대부분의 논의는 결국 버전 관리가 정말 필요한 상황인가로 귀결된다.
특히 지속적으로 배포되는 웹 서비스라면 버전 관리의 실효성이 크지 않을 수 있다는 주장들이 반복해서 등장한다.

이 지점을 우리 서비스에 그대로 대입해 봤다.

여러 버전의 소프트웨어를 동시에 운영하는가?
- 아니다. 단일 버전으로 운영한다.
명확한 출시 주기와 버전 단위 배포가 존재하는가?
- 기능 단위로 일정이 움직이고, 특정 버전에 강하게 묶이지 않는다.

이 질문들에 답해보니, develop 브랜치를 고정적으로 가져가는 Git-flow가 꼭 맞는 구조는 아니라는 생각이 들었다.

다른 브랜치 전략들

Git-flow 외에도 대표적인 전략으로 GitHub-flow, GitLab-flow가 있다.

Github-flow

Github-flow는 하나의 고정 브랜치(main)를 기준으로 모든 작업이 이루어진다.
기능 개발은 feature 브랜치에서 진행하고, 완료되면 Pull Request(PR) 를 통해 병합한다.

PR 중심으로 리뷰와 커뮤니케이션이 이루어지고, 항상 배포 가능한 상태를 유지하는 것이 핵심이다. GitHub를 사용하는 팀이라면 자연스럽게 녹아드는 방식이다.

규칙이 단순하고 지속적인 통합에 유리하지만,
팀의 개발 프로세스가 정리되어 있지 않다면 오히려 혼란을 만들 수도 있다.

Gitlab-flow

Gitlab-flow는 Github-flow의 단순함을 보완한 전략이다.
main 이후에 production 브랜치를 두고, 실제 배포는 이 브랜치를 기준으로 진행한다.

필요하다면 pre-production 브랜치를 두어 스테이징 단계를 분리할 수도 있다.
Git-flow와 Github-flow의 중간 지점에 있는 전략이라고 보면 된다.

우린 어떤 상황인가?

우리 팀의 상황을 다시 정리해봤다.

브랜치 전략
- Git-flow 사용
- release 브랜치는 사용하지 않음
서비스 유형
- 웹 애플리케이션
배포 방식
- 정기 배포

문제는 배포 과정에서 드러났다.

가장 크게 느낀 문제는 두 가지였다.

배포 일정 변경에 브랜치 전략이 잘 대응하지 못한다.
부분 배포 상황이 생기면 관리가 어렵다.

기존에는 feature → develop → main 흐름으로 배포를 진행했다.

정해진 일정에 모든 기능이 함께 나간다면 문제가 없다.
하지만 일부 기능만 먼저 배포해야 하는 상황이 생기면 develop에 섞인 커밋들 중에서 필요한 것만 골라내야 했다.

그래서 release 브랜치를 도입했다.

하지만 여기서 또 다른 문제가 생겼다.
릴리즈에서 제외된 기능을 다시 develop에 반영하는 과정이 꽤 까다로웠다. 어떤 기능이 빠졌는지 추적하기도 어렵고, rebase 과정에서도 의도치 않은 병합이 발생했다.

이 지점에서 다시 질문하게 됐다.

develop 브랜치는 정말 필요한가?

Develop-less workflow

이 질문을 따라가다 보니 develop 브랜치를 제거한 전략들이 눈에 들어왔다.
대표적으로 화해팀의 브랜치 전략과 Anti-gitflow 방식이다.

develop을 제거한 흐름은 다음과 같다.

원칙은 단순하다.

모든 브랜치는 main에서 시작한다.
기능 개발은 feature 브랜치에서 진행한다.
배포 일정이 정해지면 release 브랜치를 생성한다.
배포 대상 기능만 release에 병합한다.
테스트와 QA는 release에서 진행한다.
배포 시 release를 main으로 병합한다.
배포 후 수정은 hotfix로 처리한다.

앞서 겪었던 문제를 기준으로 보면, 이 방식은 꽤 매력적으로 느껴졌다.

흐름이 단순해서 이해하기 쉽고
각 브랜치의 역할이 명확하고
일정 변경이나 부분 배포에도 유연하다

정리

이 모든 고민은 사소한 불편함에서 시작됐다.
하지만 그 불편함을 그대로 두지 않고 이유를 찾다 보니, 지금 우리 상황을 다시 보게 됐다.

아직 적용 전이라 이론에 가깝다.
다만 필요에 의해 선택한 전략이라는 점 자체는 의미가 있다고 생각한다.

Git-flow는 여전히 좋은 전략이다.
하지만 항상 좋은 전략은 아니다.

결국 중요한 건, 지금 우리 상황을 제대로 이해하는 일이라는 생각으로 글을 마친다.