Git 브랜치 전략 개선 경험

문제

처음 입사했을 때, 회사에서는 Github flow를 사용했습니다. 하지만 실제 서비스 릴리즈 과정에서 다음과 같은 문제가 발생했습니다.

• QA 대상이 아닌 기능이 릴리즈 브랜치에 포함됨

• 특정 기능만 QA하려면 별도 브랜치를 빌드해야 하는 번거로움

• 한 번 릴리즈 브랜치에 포함됐다가 일정이 밀린 기능은 다시 빼내야 하는 불필요한 작업

결과적으로 QA 과정과 릴리즈 관리가 복잡해지고, 개발자와 QA 모두의 부담이 커진다고 느꼈습니다.

해결

문제를 해결하기 위해 브랜치 전략을 새롭게 설계했습니다.

브랜치 구조

• main: 실제 배포 브랜치

• develop: 개발 브랜치

• release: QA 전용 브랜치

• feature/*: 기능 개발 브랜치

자동화 파이프라인

• feature 브랜치를 push -> Github Actions가 자동으로 develop 에 반영

• 팀원은 develop 에서 최신 개발 상태를 바로 확인 가능

QA 프로세스

• QA가 필요한 기능만 release 브랜치에 선택적으로 merge

• QA 완료 후 해당 feature는 바로 main에 merge -> 배포 준비 완료

• 일정이 밀린 feature 브랜치라도 release 브랜치에 merge 가능

다이어그램

기존 GitHub Flow

flowchart TD
    A[main] --> B[feature-1]
    A --> C[feature-2]
    B --> A
    C --> A
    A --> QA[QA 진행]
    QA --> Release[배포]

• 모든 기능이 main에 합쳐져 QA → QA 범위 제어 불가능

개선된 전략

flowchart TD
    subgraph main[main]
    end
    subgraph develop[develop]
    end
    subgraph release[release]
    end

    A[feature-1] --> main
    B[feature-2] --> main
    main -->|GitHub Actions 자동 반영| develop
    develop -->|선택적 머지| release
    release -->|QA 완료 후| main

• feature → main 생성

• GitHub Actions → 자동 develop 반영

• QA 필요한 기능만 release에 포함

• QA 완료된 기능은 곧바로 main으로 배포 가능

성과

• QA 범위 제어가 가능해져 불필요한 테스트 감소

• 기능 제외·재반영 과정 제거 → QA 효율 향상

• 빌드 반복 최소화로 QA 리소스 절감

• 릴리즈 일정 변경에도 유연하게 대응 가능

• 컨플릭트 발생 빈도 감소

회고

이번 경험을 통해 단순히 코드 작성뿐 아니라 브랜치 전략과 협업 프로세스가 팀 생산성에 직접적인 영향을 준다는 걸 체감했습니다. 앞으로도 문제를 구조적으로 분석하고, 자동화 도구를 적극적으로 활용하여 협업 효율을 높이는 방식을 추구하고자 합니다.