ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Git flow, 깃 브러치 관리 전략
    Git 2025. 9. 8. 16:32

    1인 개발자면 크게 와닿지 않겠지만 누군가와 협업을 하다보면 형상관리를 사용할 수 밖에 없습니다. 이 형상관리에도 개념적인 전략이 있습니다. 이 전략을 따라했을때 팀원들간에 협업에 브레이크가 걸리지 않고 시너지가 날 수 있습니다.

    이런 전략 몇개 중 저는 Git Flow에 대해 얘기 해볼까 합니다.

    1. Git Flow 개요

    Git Flow는 Vincent Driessen이 제안한 Git 브랜치 모델입니다.

    주요 목적은 개발 단계별 브랜치 분리릴리즈 관리를 명확히 하는 것입니다.

    주요 브랜치 종류:

    브랜치 용도

    main (또는 master) 항상 프로덕션 배포 가능한 상태 유지
    develop 개발 중인 기능을 통합하는 브랜치, 다음 배포 대상
    feature/* 새로운 기능 개발
    release/* 배포 준비, 버그 수정, 버전 번호 관리
    hotfix/* 긴급 프로덕션 버그 수정

    2. 머지 전략 (Merge Strategy)

    Git Flow에서는 브랜치 간 병합 시 전략이 약속되어 있습니다.


    (1) Feature → Develop

    • 목적: 새 기능(feature)을 개발 브랜치(develop)에 통합
    • 브랜치 구조: feature/XXX → develop
    • 머지 방식:
      • 보통 -no-ff (non-fast-forward) 머지 사용
      • 이유: Feature 브랜치가 독립적이었음을 히스토리에 명확히 남기기 위해
    git checkout develop
    git merge --no-ff feature/test
    
    

    결과: develop 브랜치에 feature 브랜치의 히스토리가 단일 merge commit으로 남음


    (2) Develop → Release

    • 목적: 다음 배포 준비
    • 브랜치 구조: develop → release/X.Y.Z
    • 머지 방식: 일반적으로 non-fast-forward, 충돌 해결 후 배포 전 테스트
    git checkout release/1.2.0
    git merge --no-ff develop
    
    

    release 브랜치에서 최종 버그 픽스 가능, 버전 번호 수정 가능


    (3) Release → Main / Release → Develop

    • 목적:
      • Main: 실제 프로덕션 배포
      • Develop: release 브랜치에서 수정된 사항 반영
    • 머지 방식:
      • release → main: non-fast-forward
      • release → develop: fast-forward 또는 non-fast-forward (충돌 방지 위해 merge commit 권장)
    git checkout main
    git merge --no-ff release/1.2.0
    git tag -a 1.2.0 -m "Release 1.2.0"
    
    git checkout develop
    git merge --no-ff release/1.2.0
    
    

    (4) Hotfix → Main / Hotfix → Develop

    • 목적: 프로덕션 긴급 버그 수정
    • 브랜치 구조: hotfix/X.Y.Z → main, develop
    • 머지 방식: 항상 non-fast-forward, 태그로 버전 관리
    git checkout main
    git merge --no-ff hotfix/1.2.1
    git tag -a 1.2.1 -m "Hotfix 1.2.1"
    
    git checkout develop
    git merge --no-ff hotfix/1.2.1
    
    

    3. 요약

    • Fast-forward(Fast-forward merge): 단순히 브랜치가 직선으로 이어질 때 사용 가능, 히스토리 깨끗
    • Non-fast-forward (-no-ff): 브랜치 합쳤다는 기록을 남김, Git Flow에서는 주로 이 방식 사용
    • Git Flow 머지 전략 핵심:
      1. 기능 개발은 feature → develop
      2. 배포 준비는 develop → release
      3. 배포 완료 후 main, develop에 반영
      4. 긴급 수정은 hotfix → main → develop

     

    혼자 프로젝트 하나 만들어서 장난감처럼 좀 가지고 놀다보면 대략적인 흐름은 금방 이해할 수 있습니다.

    댓글

#dev-hahm#