(7)-4.Git Flow

Git을 사용하려고 보면 참 많은 것 들이 있습니다.

Bitbucket, Git Hub, GIt Lab, Git Swarm, Git Flow 등

이 중에서 성격이 다른게 하나 있는데 바로 지금 언급하고자 하는 Git flow입니다.

다른 것들은 Git을 사용하는 제품 이름인데 반해 Git flow는 Git을 사용하는 Branch 전략 기법이지요

이번 내용은 이 Git flow에 대해 살펴 보겠습니다.

일반적인 과거의 버전관리 도구를 사용하다가 Git으로 전환하는 경우,

또는 Git을 도입은 했으나 사용을 위해 초기 서버 설정을 해야 하는 경우 등

많은 사람들이 Git을 사용해 작업을 하고자 할 때,가장 우선 고민하게 되는 문제는 어떤 형태로 버전을 관리해야 할 지 입니다.

Git의 장점인 Branch를 활용은 해야겠고, 그러자니 기존에 관리하던 방식과는 다른 듯 한데 막상 구성하자니 어디서부터 손을 대야 할 지 막막하지요.

더군다나 DVCS인 GIT의 특성 상 기존 서버-단말 개념의 버전관리가 아닌 사용자 중심의 버전 관리 개념도 다가서기 손쉽지 않은데 서버 정책 까지 정의하려니 이만저만 골치 아픈게 아닙니다.

대부분 조직 또는 팀 내부에서 많은 토론을 거쳐 정의하는 과정을 거치지만 과연 이게 올바른 결정인가 하는 고민도 항상 꼬리표 처럼 따라 붙습니다.

이런 때 참고하거나 적용 할 수 있는 Best practice 즉, 가장 널리 알려지고 유용한 Reference가 바로 Git flow입니다.

Git flow는 Vincent Driessen 라는 개발자가 자신의 경험을 바탕으로 정리한 Branch전략을 기반으로

사용자들이 보다 손쉽게 적용이 가능하도록 자동으로 Branch를 만들어 주는 기능을 제공합니다.

당연히 사용 방안에 대한 가이드도 제시하고 있지요.

이런 이유로 Git flow는 현재 Git을 사용하는 사용자라면 반드시 참고해 봐야 할 또는 적용해야 할 훌륭한 사용 기법으로 각광받고 있는데요

이 Git flow는 Branch 작업에 대해 다음과 같은 모델을 표준 가이드로 제시합니다.

(출처: http://nvie.com/posts/a-successful-git-branching-model/)

Git flow를 구성하는 기본 Branch는 GUI도구 등에서 자동으로 생성 할 수 있도록 제공 되기 때문에

처음 Git을 설정하는 분이라 할 지라도 간단한 설치만 진행하면, Git의 훌륭한 기본 Practice 기반의 사용 환경을 구축 할 수 있습니다.

Vincent의 branching model은 “feature – develop – release – hotfixes – master” 단계로 branch를 나눠서 코드를 관리하는 전략인데

Git flow는 바로 이 내용을 기반으로 환경을 구성하며 주요 Branch는 다음과 같은 용도를 기반으로 합니다.

기본 Branch

Feature : 개발하고자 하는 기능을 위한 branch

Release : 제품 또는 결과물을 Release하기 위한 브랜치

    - develop branch에서 가져오며, develop 과 master branch로 머지한다.

    - release-* 형태로 이름을 짓는다. 예를 들어, 다음 릴리즈 버전이 1.2라면, release-1.2 라고 한다.

    - branch를 생성한 후, 소스 코드 내에 버전과 관련된 값을 수정하고 커밋한다.

    - 다음 릴리즈까지 개발이 최종 완료되었다고 판단하는 시점에서 branch를 생성한다.

    - 릴리즈 대상이 되는 feature 는 미리 develop에 머지되어 있어야 하고,

      다음에 릴리즈할 feature 라면 develop에 머지되어 있으면 안된다.

    - release branch를 생성한 이후의 버그 픽스는, develop 이 아닌 release branch에서 진행한다.

    - 릴리즈가 모두 준비되었다고 생각하면, release branch를 master 에 머지한다.

    - master branch에서 해당 버전으로 태그를 생성한다.

    - release branch에서 버그 픽스한 것들을 develop branch로 머지한다.

    - release 가 종료되면, release branch를 삭제한다.

Hotfix : 긴급 버그 픽스를 위한 브랜치

몇 가지 주의할 점은 다음과 같다.

  - 브랜치를 머지할 때 --no-ff 옵션을 쓴다.

      fast forward 머징을 하지 않고, 머지 커밋을 생성하겠다는 의미다.

      머징 히스토리를 유지하기 위함이다.

  - 가능하다면 버전 정보는 소스 코드 내에서 직접 작성하지 않는다.

      버전과 관련된 정보를 찾아 현재 버전으로 업데이트하는 스크립트를 작성하자.

이 Git flow는 훌륭한 기반 환경의 표준을 제공하며 많은 장점을 제공하지만 단점도 있는데, 장 단점은 다음과 같습니다.