Git 브랜치 전략 정리

Git Flow

• Main
  출시 가능한 프로덕션 코드를 모아두는 브랜치

• Develop
  다음 버전 개발을 위한 브랜치, Main으로 머지됨

• Supporting

  • Feature
    하나의 기능을 개발하기 위한 브랜치. Develop에서 생성되며, Develop로 머지됨 feature/branch-name

  • Release
    배포를 준비하기 위한 브랜치. Develop에서 생성됨
    버전이름, 사소한 버그 수정
    Main, Develop로 머지
    release/v1.1

  • Hotfix
    이미 배포된 버전에 문제가 발생할 때 사용
    Main에서 생성
    Main, Develop로 머지
    hotfix/v1.0.1

Main, Develop 브랜치는 개발 프로세스 전반에 유지되고

Supporting 브랜치는 필요할 때만 생성되고 역할을 다하면 삭제된다.

소프트웨어 버전 관리가 필요한 경우 적합하다(앱, 솔루션…)

웹 어플리케이션에는 적합하지 않다고 함

Github Flow

트렁크 기반 개발의 일종이라 한다.

Main, Topic 브랜치 두 개로 구성된 전략이다.

• Main
  항상 Stable 한 상태여야 한다. (언제 배포하든 상관 없는 상태)
  Main 브랜치의 모든 커밋은 빌드가 되고, 테스트를 통과해야 한다.

• Topic
  새로운 기능을 개발할 때 사용
  Main 브랜치로부터 생성한다.
  이름은 기능을 설명하는 이름으로 네이밍한다.
  커밋은 기능이 완성되지 않더라도 꾸준히 푸쉬한다
  기능이 완성되고 코드 리뷰가 끝나면 Main으로 머지한다.

개발팀이 소규모이고 제품이 단일 릴리즈 버전만 존재할 경우 적합하다.

Gitlab Flow

Git Flow와 Github Flow의 장점을 결합한 유연한 브랜치 전략이다.

• Master
  안정적인 코드가 저장되는 브랜치

• Feature
  각 기능이 개발되는 브랜치
  Master 브랜치에서 만들어지고 완료되면 다시 머지됨

• environment
  개발, 스테이징, 프로덕션과 같은 다양한 환경에서 코드를 배포할 때 사용된다.

• release(선택사항)
  릴리스를 위해 사용된다.
  master에서 파생되며 릴리스 준비가 끝나면 다시 master로 머지된다.

• hotfix(선택사항)
  버그 패치 브랜치
  master에서 파생되며 수정 후 master로 머지된다.

유연성과 환경관리가 중요한 프로젝트에 적합하다.