Git - Branching Model

• 브랜치 전략은 왜필요할까?
  • Git은 복잡하며, work flow는 아무런 제약이 없다.
    • 그렇기 때문에 조직의 특성과 성향에 맞는 Branching Model을 찾아야하며, 일정 규칙이 필요할 것이다.
  • 조직에 맞게 잘 정의한 work flow는 효율을 크게 상승시킬 수 있다.
    • 개발 History 관리 가능
    • 코드 리뷰를 통한 코드의 품질 향상
    • 브랜치 관리
    • 배포 관리를 통한 사고 & 장애 대응가능

 

• (1) Git Flow Model
  • Vincent Driessen이 제시한 model
  • 가장 보편적인 branching model이며, tool도 구현되어 있다. 하지만, 복잡하고 애매하며 특히 개발 이력 관리가 많이 어렵다는 단점이 존재한다.
  • 예를들어, 우아한 형제들에서 제시한 방법이 Git Flow를 Base로 하고있다.
    (http://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html)
    
    
  • 주요 브랜치 & 보조 브랜치에 대한 설명

                       (주요 브랜치)

• • • develop
      => 모든 코드를 포함하고 있는 기본 개발 브랜치
    • master
      => 배포 브랜치. 일반적으로 git hook을 걸어 자동 배포하게 설정해서 사용한다. (CI / CD Tool을 활용하는 경우도 있다)

                       (보조 브랜치)

• • • feature
      => 기능 개발 목적
    • release
      => 배포를 위한 QA 목적
    • hotfix
      => 배포이후 운영중에 발견한 버그수정의 목적 - 긴급상황이기 때문에, 수정후 즉시 배포
    • bugfix
      => release 보조 브랜치에서 발생한 버그를 바로 수정하는 목적 - 수정후 release branch로 pull request
  • Git Flow의 흐름

• (2) GitHub Flow
  • Git Flow는 복잡하고 GitHub에 맞지 않아, scott chacon이 제시한 model이다.
  • 단순하다. (보조 branch를 정의하지 않는다)
  • master branch(=배포 브랜치)만 엄격하게 관리한다.
    => 실제 라이브운영환경에 적용되기 때문에, Pull Request가 중요하다.
  • 특정 인원에게 권한이 집중될 수 있다.
    
    
  • GitHub Flow의 흐름

•  (3) GitLab Flow
  • GitLab Flow는, 위에서 설명한 GitHub Flow에 내용을 보완하여 제안한 방식이다.
    => master 브랜치 이외에 production 브랜치를 추가한다. master브랜치는 기존대로 엄격하게 관리하는데, 배포를 목적으로 하지는 않으며, production 브랜치에서 배포를 담당한다.
    => pre-production 브랜치를 정의하여 배포전에 테스트를 할 수 있도록 만들어 볼 수도 있다.
    
    
  • GitLab Flow는 사용자의 의도대로 배포할 수 없는 환경일 때 적절하다.
  • GitLab은 work flow와 issue tracking system을 연동 및 통합시킴으로써 단순하고 투명하며 효율적인 작업을 가능하게 한다.
    
    
  • GitLab의 흐름