Git 브랜치 전략: Trunk-Based에서 GitHub Flow로의 여정

안녕하세요! 오늘은 개발 팀의 생산성과 코드 품질에 큰 영향을 미치는 Git 브랜치 전략에 대해 이야기해보려고 합니다. 특히 제가 경험한 Trunk-Based Development에서 GitHub Flow로의 전환 과정을 중심으로 실제 적용 사례와 배운 점들을 공유하겠습니다.

주요 Git 브랜치 전략 비교

저는 주로 세 가지 브랜치 전략을 경험해보았습니다: Git Flow, GitHub Flow, 그리고 Trunk-Based Development입니다. 각 전략의 특징을 간략히 살펴보겠습니다.

 

Git Flow

Git Flow는 가장 구조화된 브랜치 전략입니다:

• feature 브랜치: 모든 새로운 기능 개발은 여기서 시작
• develop 브랜치: 개발 중인 기능들이 모이는 통합 브랜치
• release 브랜치: 출시 준비를 위한 브랜치로, QA와 버그 수정이 이루어짐
• main 브랜치: 프로덕션 코드만 존재하는 안정적인 브랜치
• hotfix 브랜치: 프로덕션 환경의 긴급 버그 수정을 위한 브랜치

장점: 안정적이고 체계적인 릴리스 관리, 명확한 역할 구분 단점: 복잡한 구조, 많은 브랜치 관리의 부담, 병합 충돌 가능성 증가

 

GitHub Flow

GitHub Flow는 Git Flow를 단순화한 전략입니다:

• main 브랜치: 항상 배포 가능한 상태 유지
• feature 브랜치: main에서 분기하여 기능 개발 후 PR을 통해 코드 리뷰 진행
• 리뷰 완료 후 main에 병합과 동시에 배포 가능

장점: 단순한 워크플로우, 빠른 피드백, CI/CD와의 좋은 통합 단점: 안정성 관리를 위한 별도 프로세스 필요, 동시 릴리스 관리가 어려울 수 있음

 

Trunk-Based Development

Trunk-Based Development는 가장 단순한 전략입니다:

• trunk(main) 브랜치: 개발의 중심이 되는 단일 브랜치
• 짧은 수명의 feature 브랜치 또는 직접 trunk에 커밋
• 지속적인 통합과 배포를 통한 빠른 피드백

장점: 병합 충돌 최소화, 빠른 개발 주기, 간편한 관리 단점: 높은 수준의 자동화 필요, 코드 품질 관리의 어려움

 

우리 팀의 Trunk-Based에서 GitHub Flow로의 전환 여정

기존 Trunk-Based Development의 한계

저희 회사에서는 처음에 Trunk-Based Development 방식으로 개발을 진행했습니다. 초기 스타트업으로서 빠른 개발과 배포가 중요했기 때문입니다. 모든 개발자가 main 브랜치에 직접 커밋하거나 매우 짧은 수명의 feature 브랜치를 사용했습니다.

하지만 시간이 지나면서 몇 가지 문제점이 드러났습니다:

1. 코드 품질 관리의 어려움: 코드 리뷰 없이 바로 main에 병합되는 경우가 많아 품질 저하 발생
2. 배포 전 테스트 부족: 지속적인 통합은 되었지만, 배포 전 충분한 테스트 시간 확보가 어려움
3. 동시 개발의 복잡성: 팀이 성장하면서 여러 기능을 동시에 개발할 때 관리가 어려워짐
4. 릴리스 계획의 어려움: 특정 기능들을 묶어서 릴리스하기 어려운 구조

GitHub Flow로의 전환 과정

이러한 문제들을 해결하기 위해 저는 팀에 GitHub Flow로의 전환을 제안했습니다. 복잡한 Git Flow는 우리 팀의 규모와 릴리스 주기에 비해 과도하다고 판단했고, 대신 GitHub Flow가 적절한 절충안이 될 것이라 생각했습니다.

전환 과정은 다음과 같았습니다:

1. 팀 교육 및 합의

가장 먼저 팀원들에게 GitHub Flow의 장점과 도입 이유에 대해 설명하는 시간을 가졌습니다. 모든 팀원이 새로운 워크플로우를 이해하고 동의하는 것이 중요했습니다.

2. 브랜치 보호 규칙 설정

main 브랜치에 대한 보호 규칙을 설정했습니다:

• 직접 푸시 금지
• PR을 통한 병합만 허용
• 최소 1명 이상의 코드 리뷰 승인 필요

3. PR 템플릿 및 리뷰 프로세스 정립

효율적인 코드 리뷰를 위해 PR 템플릿을 만들었습니다:

## 변경 사항 설명
- 

## 관련 이슈
- #이슈번호

## 테스트 방법
1. 

## 스크린샷 (필요시)

## 체크리스트
- [ ] 문서화 완료
- [ ] 코드 리뷰어 지정

전환 후 얻은 효과

GitHub Flow로 전환한 후 3개월 동안 다음과 같은 개선 효과를 확인할 수 있었습니다:

1. 코드 품질 향상: 모든 코드가 리뷰를 거치면서 버그 발생률이 약 30% 감소
2. 협업 증가: PR 기반 개발로 팀원 간 지식 공유와 협업이 활발해짐
3. 개발 속도 유지: 초기에는 프로세스 추가로 속도가 느려질까 우려했으나, 장기적으로는 버그 수정 시간이 줄어 전체 개발 속도 유지

적용 시 배운 교훈

GitHub Flow로의 전환 과정에서 몇 가지 중요한 교훈을 얻었습니다:

1. 팀 규모와 프로젝트 특성에 맞는 전략 선택이 중요

브랜치 전략은 팀의 규모, 제품 특성, 릴리스 주기에 맞게 선택해야 합니다. 우리의 경우:

• 10명 내외의 개발팀
• 2주 단위의 릴리스 주기
• 웹 서비스 제품

이런 환경에서는 GitHub Flow가 Git Flow보다 더 적합했습니다.

 

2. 문서화와 가이드라인의 중요성

새로운 워크플로우의 성공적인 정착을 위해 명확한 문서화와 가이드라인을 제공했습니다:

• 브랜치 네이밍 컨벤션
• 커밋 메시지 형식
• PR 작성 가이드
• 코드 리뷰 에티켓

 

결론: 상황에 맞는 유연한 접근이 중요

브랜치 전략에는 절대적인 정답이 없습니다. 중요한 것은 팀과 프로젝트의 상황에 맞게 유연하게 접근하는 것입니다.

• Git Flow: 릴리스 주기가 길고, 여러 버전을 동시에 관리해야 하는 대규모 프로젝트에 적합
• GitHub Flow: 지속적 배포를 하면서도 코드 품질 관리가 필요한 웹 서비스에 적합
• Trunk-Based Development: CI/CD가 완벽하게 갖춰진 환경에서 빠른 개발 속도가 필요할 때 적합

저희 팀은 Trunk-Based에서 GitHub Flow로 전환함으로써, 개발 속도를 유지하면서도 코드 품질과 협업 효율성을 높일 수 있었습니다. 여러분의 팀에도 이런 경험이 참고가 되었으면 합니다.