Git과 브랜치의 복잡함
2005년 리눅스 커뮤니티에서 탄생한 Git은 GitHub의 웹 UI와 함께 인기를 얻은 분산 버전 관리 시스템으로, 적극적인 브랜치 활용을 권장한다. 하지만 특징을 이해하지 못하면 복잡한 커밋 그래프 앞에서 어디서부터 잘못됐는지 알 수 없게 되며, 하나의 정답이 아니라 선구자들이 남긴 방법론을 살펴보자고 제안한다.
빈센트 드리센이 소개한 Git flow는 배포 코드를 모으는 master와 다음 버전을 개발하는 develop 두 메인 브랜치를 중심으로 한다. feature 브랜치는 always merge commit으로 기능 단위 히스토리를 묶고, release 브랜치는 배포 준비를, hotfix 브랜치는 배포 버전의 긴급 수정을 담당한다. 규칙은 많지만 기계적으로 지키면 안정적으로 협업할 수 있다.
GitHub flow는 Git flow가 대부분의 경우 너무 복잡하다고 보고 훨씬 간단한 절차를 택한다. master는 항상 stable해야 한다는 유일한 규칙 아래 topic 브랜치를 만들고, 개발 도중에도 Pull Request를 열어 스크린샷·질문·리뷰를 공유한다. Hubot 봇이 CI 통과·배포 락·master 반영을 체크한 뒤 배포하며, 2012년 하루 평균 약 50회, 최대 175회 배포를 기록했다.
GitLab flow는 Git flow의 release/hotfix가 지속적 배포 환경에선 불필요하고, GitHub flow는 배포 스테이지·환경 통합 설명이 부족하다고 지적한다. 배포 시간이 정해진 경우 production 브랜치를, 여러 환경엔 staging→pre-production→production 순 환경별 브랜치를, 릴리스 소프트웨어엔 버전 브랜치와 upstream first cherry-pick을 쓰는 케이스별 모범 사례를 제시한다.
여러 서비스와 다양한 일정이 동시에 진행되는 상황에서, 발표자 팀은 Git flow를 기반으로 하되 develop 역할을 하는 개발 일정 브랜치를 여러 개 둔다. 각 일정 브랜치에서 feature 브랜치를 파고 PR로 리뷰한 뒤 rebase로 히스토리를 정돈하며, QA 완료 후 master·develop에 머지한다. 나머지 일정 브랜치는 rebase(-p)로 재정렬해 정돈된 커밋 그래프를 유지한다.
전반적인 개발 플로우로, 업무는 이슈 트래커 성격의 Dooray! 프로젝트에서 생성하고 커밋 메시지에 업무 번호를 남긴다. Pull Request에는 브랜치 보호 설정으로 코드 리뷰 승인과 테스트 통과, develop 최신 반영을 강제한다. Jenkins로 pre-merge 테스트를, SonarQube로 버그·취약점·코드 스멜을 잡는 정적 분석을 붙여 기계적인 검증은 기계에 맡긴다.
규칙만 지키면 탈이 적은 Git flow, master는 stable해야 한다는 대원칙으로 스피드를 내는 GitHub flow, 현실의 다양한 케이스별 브랜치 모델을 소개한 GitLab flow, 그리고 팀 자체 워크플로를 정리한다. 브랜치 전략·rebase·pre-merge 테스트·정적 분석 각각에 대해 자신만의 답을 찾으라며, 하나의 진리는 없으니 상황에 맞게 응용하라고 마무리한다.