ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Git 브랜치 전략(feat. Git Flow, Github Flow, Gitlab Flow)
    Git 2023. 7. 4. 23:07
    반응형

    깃 브랜치 전략(Git Branch Strategy)

     

    Git에서는 동시에 여러 작업을 할 수 있게 Branch를 사용합니다. 작업 영역을 분리하여 수정하고 관리하고 원래 버전과 합칠 수도 있습니다. 이런 Git의 Branch를 관리하는 전략들을 Git Branch Strategy(깃 브랜치 전략)이라고 합니다!

     

    Git Branch 전략의 종류

    1. Git Flow
    2. Github Flow
    3. Gitlab Flow

     

    Git Flow

    깃 브랜치 전략이라고 하면 가장 먼저 떠오르는 굉장히 많은 회사와 팀에서 사용하고 있는 전략입니다.

     

    특징

    1. 용도에 맞게 브랜치를 분리해서 사용(feature > develop > release > hotfix > master)
      1. 병합 순서는 앞에서부터 뒤로 병합
      2. develop과 master 브랜치는 중심이 되는 브랜치라서 무조건 있어야 함
    2. 명확한 릴리즈 버전 관리를 위한 브랜치를 따로 관리하기 때문에 한 버전에 대한 유지보수가 용이함
    3. 기능 개발 단위 사이사이의 conflict를 최소화 할 수 있음
    4. 명확한 배포 기간과 주기적인 버전이 정해진 프로젝트에 적합

     

    간단 브랜치 설명

    Git Flow에는 5가지 종류의 브랜치가 있습니다.

    • master
      • 제품으로 출시될 수 있는 브랜치
    • develop
      • 다음 출시 버전을 개발하는 브랜치
    • feature
      • 단위 기능을 개발하는 브랜치
    • release
      • 이번 출시 버전을 준비하는 브랜치
    • hotfix
      • 출시 버전에서 발생한 크리티컬한 버그를 긴급 수정하는 브랜치

    branch를 merge 할 때는 항상 —no-ff 옵션을 붙여서 branch에 대한 기록이 사라지는 것을 방지하는 것이 원칙

     

    과정 설명

    • master에서 develop을 분기
    • 개발자들은 develop 브랜치에 자유롭게 커밋
    • 기능 구현이 있는 경우 develop에서 feature-* 브랜치를 분기
    • 배포를 준비하기 위해 develop에서 release-* 브랜치를 분기
    • 테스트를 진행하면서 발생하는 버그 수정은 release-* 브랜치에 직접 수정 및 반영
    • 테스트가 완료되면 release 브랜치를 master와 develop에 merge

    Git flow 흐름도
    Git flow 흐름도

     

    Github Flow

    Git Flow가 Github에서 사용하기에 너무 복잡하고 절차가 많다 해서 고안된 브랜치 전략입니다.

     

    특징

    1. Git Flow에 비해 굉장히 간단함
    2. master 브랜치와 pull request 방식을 활용하여 굉장히 단순한 형태
    3. Git Flow와는 다르게 hotfix 브랜치나 feature, release 브랜치를 구분하지 않음 (우선순위는 존재)
    4. 수시로 배포가 일어나고, CI/CD 파이프라인이 구성되어 있는 프로젝트에 유용

     

    간단 브랜치 설명

    • master
      • 프로젝트의 기둥
      • 프로젝트를 product에 배포할 때 사용되는 브랜치
    • 새로운 브랜치
      • 새로운 일을 시작하기 위해 만드는 브랜치
      • 항상 master에서 분기
      • Git Flow와는 다르게 feature, release, develop 등을 나누지 않음
      • 자세하게 어떤 일을 하고 있는지에 대해 알수있도록, 이름을 명확히 작성해야 함
      • 커밋 메시지를 명확하게 작성해야 함
      • merge 준비가 완료되면 Pull Request를 생성하여 코드를 공유하고 리뷰함
      • Pull Request에서 리뷰가 완료되었다면 master 브랜치로 반영을 요구함

     

    과정 설명

    • master에서 새로운 브랜치를 분기
    • 기능 개발 완료 시 master에 Pull Request 생성
    • Pull Request에서 코드 리뷰
    • 리뷰 및 테스트 완료 시 master 브랜치로 merge
    • master 브랜치에서 배포(자동 배포를 사용 시 더욱 편함)

    Github flow 흐름도
    Github flow 흐름도

     

    Gitlab Flow

    복잡한 Git Flow와 너무 간단한 Github Flow의 절충안

     

    특징

    • Production 브랜치가 존재(Git Flow의 master 브랜치 역할과 같음)
    • Gitlab Flow의 master 브랜치는 production 브랜치로 병합됨
    • pre-production 브랜치는 production 브랜치로 넘어가기 전에 테스트를 진행하는 브랜치

     

    간단 브랜치 설명

    • master
    • pre-prodution
      • production으로 넘어가기 전의 브랜치
      • 테스트 등을 담당
    • production
      • 배포만을 담당
    • 새로운 브랜치
      • github flow의 새로운 브랜치처럼 사용

     

    과정 설명

    Github Flow에서 배포만을 위해 추가된 Production 브랜치와 테스트를 위한 Pre-production 브랜치 빼고 동일합니다.

    Gitlab flow 흐름도
    Gitlab flow 흐름도


    참고

    https://techblog.woowahan.com/2553/

    https://blog.gangnamunni.com/post/understanding_git_flow/

    https://velog.io/@kw2577/Git-branch-전략

    https://sungjk.github.io/2023/02/20/branch-strategy.html

    https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/

    반응형

    'Git' 카테고리의 다른 글

    Git branch 나누고 합치기  (0) 2022.04.06

    댓글

Designed by Tistory.