Git-flow 소개

개요

Git-flow는 Git이 새롭게 활성화되기 시작하는 10년전 쯤에 최초로 Vincent Driessen이라는 사람의 블로그 글에 소개되어 널리 퍼지기 시작했고 현재는 Git으로 개발할 때 거의 표준과 같이 사용되는 브랜치 전략입니다.

 

브랜치 종류

Git-flow에서 제시하는 브랜치 종류는 아래와 같이 크게 두 가지로 나뉘며 하위로 총 5개의 브랜치가 존재합니다.

• The main branches
  • master: 실제 릴리즈할 소스코드를 위한 브랜치
  • develop: 다음 릴리즈에 포함될 최신 구현 내용(기능)들이 반영되는 브랜치
• Supporting branches
  • feature: 새로운 기능을 개발하기 위한 브랜치
  • release: 다음 버전의 릴리즈를 준비하기 위한 브랜치
  • hotfix: 릴리즈 버전의 버그 수정을 위한 브랜치

Git-flow의 전체적인 작업흐름은 아래와 같이 흘러갑니다.

이제 각 브랜치들을 좀 더 상세히 알아보겠습니다.

The main branches

위 두 메인 브랜치들은 원격 레포지토리와 함께 영구적으로 유지되는 브랜치입니다.

각 브랜치는 다음과 같은 특성을 엄격히 유지하여야 합니다.

• master: 항상 실제 서비스가 가능한 상태의 소스코드를 유지해야함.
• develop: 항상 다음 릴리즈를 위해 개발되어지는 모든 변화가 반영되어 짐.

기본적인 작업흐름은 develop 브랜치의 소스코드가 릴리즈에 필요한 기능들이 모두 반영되어진 후, 안정적인 시점일 때 develop 브랜치의 모든 변화를 master 브랜치에 merge합니다.

Supporting branches

메인 브랜치를 보조하는 브랜치들로 팀원들이 각자의 작업을 동시에 진행할 수 있도록 도우며 (parallel development) 또한 누가 어떤 기능을 개발하여 반영하였는지 추적을 돕습니다. 그리고 제품의 릴리즈를 준비할 수 있도록 돕고 실제 서비스 중인 제품의 예기치 못한 버그를 수정하는 것을 보조합니다.

위에 서술된 보조역할을 featrue, release, hotfix 브랜치가 나누어 수행하게 되는데, 각 보조 브랜치들을 알아보겠습니다.

Feature branches

브랜치 생성 from: develop

머지 to: develop

브랜치 네이밍 컨벤션: master, develop, release-, hotfix- 를 제외하고 모든 형식 가능

 

feature 브랜치는 develop 브랜치에서 새로운 기능(new feature)를 반영해야할 때 생성할 수 있습니다. feature 브랜치는 개발중일 때만 존재할 수 있도록 규정하며, 끝으로는 develop 브랜치에 merge 하도록 합니다.

feature 브랜치는 관례상, 해당 feature의 책임을 할당 받은 개발자의 local 저장소에만 존재하도록 유지하며 origin에 반영하지 않도록 합니다.

 

feature 브랜치를 통해 개발하고 개발된 기능을 develop에 반영하면 아래의 이점을 얻을 수 있습니다.

• 각자의 작업을 동시에 진행할 수 있도록 돕는다. (parallel development)
• 누가 어떤 기능을 개발하여 반영하였는지 추적이 용이해짐.

 

feature 브랜치를 활용할 때와 feature 브랜치를 활용하지 않을 때

       

다수의 개발자가 각자의 작업 브랜치에서 같은 소스코드를 건드렸다면 결국엔 develop에 merge시 conflict가 발생하겠으나 적어도 feature 브랜치에서 작업중일 때 방해받지 않을 수 있습니다!

 

작업 흐름

1. 1. develop 에서 feature branch 를 생성해서 새로운 작업을 시작합니다.
      • ex. feature/ISSUE-101
   2. feature branch 에서 작업이 끝나면 feature branch 를 최신 develop 에 merge 합니다.
   3. conflict 없이 깔끔하게 해결! 

 

Release branches

브랜치 생성 from: develop

머지 to: develop, master

브랜치 네이밍 컨벤션: release-*

 

릴리즈 브랜치는 이름 그대로 새로운 릴리즈를 준비하도록 도와주는 브랜치입니다. develop 브랜치에서 다음 릴리즈를 위한 개발이 완료되었다는 판단이 설 때 생성할 수 있습니다. 릴리즈 브랜치가 존재하는 주기 동안은 QA를 거치는 동안 발생하는 버그 수정이나 추가 변경사항을 반영하고 릴리즈 시 필요한 메타데이터(버전 넘버, 빌드일자 등)를 추가하는 등의 작업을 진행합니다.

develop을 통해 생성하는 것을 원칙으로 하며 새로운 릴리즈를 위한 준비가 다 끝났다면 변경 사항을 develop, master 브랜치 양 쪽에 머지하여 반영합니다.

 

작업 흐름

1. 1. develop 에서 release branch 를 생성해서 새로운 작업을 시작합니다.
      • ex. release/1.1.0
   2. release branch 에서 version bumping, minor bug fix 등의 작업이 끝나면 release branch 를 최신 develop 과 master 에 각각 merge 합니다.
      • develop: release branch 에서의 bug fix 등 수정 사항들이 develop 에도 반영되어야 하기 때문에
      • master: 새 version 을 release 하기 위해
   3. master 의 merge commit 에 version 을 tag 로 붙여줍니다.
      • ex. 1.1.0
   4. 이렇게 하면 release branch 를 생성한 후에 develop 에 어떤 작업이 merge 되었어도 안전하게 배포 성공!

Hotfix branches

     

브랜치 생성 from: master

머지 to: develop, master

브랜치 네이밍 컨벤션: hotfix-*

 

hotfix 브랜치는 마찬가지로 릴리즈 준비를 돕는 브랜치라고 할 수 있습니다. 다만 릴리즈 상태인 master 브랜치에서 예기치 못한 버그나 추가변경사항 등과 같은 문제가 생겼을 때 즉각 조치하기 위해 사용합니다.

해당 hotfix 작업이 끝날 때는 develop, master 두 브랜치에 모두 반영해줍니다.

 

hotfix 브랜치를 활용하지 않을 때

위 그림에서 hotfix 브랜치를 활용하지 않고 develop에서 1.0 버전의 프로덕트의 문제를 수정하고 merge할 때, develop 브랜치에서 다음 버전을 위해 개발되던 소스코드까지 같이 반영이 되어버릴 수 있다!!

 

작업 흐름

1. 1. master 에서 hotfix branch 를 생성해서 bug fix, version bumping 등의 작업을 진행합니다.
      • ex. hotfix/1.1.1
   2. hotfix branch 에서 작업이 끝나면 hotfix branch 를 최신 develop 과 master 에 각각 merge 합니다.
      • develop: hotfix branch 에서의 bug fix 등 수정 사항들이 develop 에도 반영되어야 하기 때문에
      • master: 버그가 수정된 새 version 을 release 하기 위해
   3. master 의 merge commit 에 version 을 tag 로 붙여줍니다.
      • ex. 1.1.1
   4. 이렇게 하면 develope 의 작업과 상관없이 master에 hotfix 변경사항 반영 완료!

 

마무리

Git-flow는 2010년 5월에 처음 소개되고 나서 지금까지도 수많은 개발팀에서 각광받는 좋은 Git 브랜치 전략입니다! 이를 잘 활용하면 Git을 활용한 프로젝트 개발에 있어 큰 도움이 될 수 있습니다.

다만 Git-flow가 완벽한 것은 아닙니다. 2010년 5월 현재 대표적인 브랜칭 전략인 Git flow를 처음 소개한 Vincent Driessen는 현재 대부분의 사람들이 Git flow를 너무 맹신하고 있다고 비판하며 지속적으로 배포가 되는 소프트웨어를 개발하는 팀의 경우 GitHub flow와 같은 더욱 단순한 workflow를 추천한다고 합니다. 이와 관련하여 Git flow를 비판하는 유명한 글도 있으니 궁금하시다면 한 번 확인해보세요!!

하지만 버전이 명확하게 관리되어 지는 소프트웨어를 개발하는 경우와 다양한 버전의 소프트웨어가 서비스 되어지는 경우에는 여전히 Git-flow는 좋은 전략으로 받아질 수 있을 것이라고 합니다. 그러니 팀에게 주어진 상황을 잘 고려하여 workflow를 결정하고 활용하면 되겠습니다.