Git-flow란?

페스타고의 깃 브랜치 전략을 정하는 과정에서 git-flow에 대해 알게됐다.

git-flow가 무엇인지 알아보자.

 

 

아래의 이미지는 git-flow의 흐름을 담은 가장 유명한 그림이다.

나도 아래 그림을 보고 git-flow에 대해 처음 알게되었다.

출처: 강남언니 기술블로그 (https://blog.gangnamunni.com/post/understanding_git_flow/)

 

git-flow에서 브랜치의 종류는 크게 main(master) / hotfix / release / develop / feature 인데, 위 이미지를 보면 상당히 복잡해서 이해하기 어렵다.

 

 

git-flow 흐름을 이해하기 위해 직접 그려본 그림이다.

조금 더 간략하게 그려봤지만, 여전히 그림만으로는 git-flow를 이해하기는 어렵다.

git-flow를 이해하기 위해, 브랜치의 종류별 역할을 알아보도록 하자.

 

main & develop

git-flow에서 핵심이 되는 두 브랜치이다.

이 브랜치들은 한 번 생성되면 삭제되지 않고, 계속해서 사용된다.

 

(위 두 브랜치를 제외한 다른 브랜치들은, 해당 브랜치들은 필요할 때 마다 생성되고 역할을 다 하면 삭제된다. 이들은 개발자들이 여러 작업을 병렬적으로 할 수 있도록 돕는다. )

 

main(master) 브랜치

이 브랜치는 production(운영) 출시 버전의 코드 모음집이다.

해당 브랜치는 프로젝트 시작시 생성된다.

주로 해당 브랜치는 릴리즈 태그가 된 커밋들만 포함된다.

 

모바일 어플리케이션의 경우, 주로 앱스토어에 출시된 버전별 코드들이 main 브랜치에 기록된다.

 

develop 브랜치

이 브랜치는 지속적인 개발의 통합 브랜치이다.

다시 말해, 이 브랜치로 기능별 커밋이 모이게 된다.

 

해당 브랜치는  main 브랜치에서 분기되며, 한 버전의 개발이 완료되면(출시 가능 상태가 되면) main 브랜치로 머지시킨다.

이 브랜치는 아직 개발 중인 기능이 포함될 수 있다. (출시 가능 상태가 아닐 수 있다.)

 

feature 브랜치

하나의 기능을 개발하기 위한 브랜치이다.

깃허브 이슈단위로 하나의 feature 브랜치가 생성될 수 있다.

 

기능별로 develop에서 분기되며, 기능 개발이 완료되면 다시 develop 브랜치로 머지시킨다.

(머지 후 해당 브랜치는 역할을 다 한 것으로 판단하여 삭제시킨다.)

 

기능별로 다른 feautre 브랜치로 분기해 작업함으로써, 여러 기능을 병렬적으로 작업할 수 있다. 

 

release 브랜치

운영 버전으로의 출시 준비를 위한 브랜치이다.

 

이 브랜치는 develop 브랜치에서 한 버전에 대한 기능개발이 완료되었다고 판단되었을 때 분기된다.

해당 브랜치의 코드로 운영 서버로 가기 전 최종 점검(QA)을 진행한다.

QA에서 버그 발생시, 해당 브랜치에서 수정한다.

 

QA 진행 완료 후, main 브랜치와 dev 브랜치로 머지시킨다.

(QA 진행시 변경된 코드를 dev 브랜치에도 반영해야하기 때문이다.)

 

hotfix 브랜치

이미 출시된 버전에 버그가 발생 할 경우, 해당 버그를 수정하기 위한 브랜치이다.

(말 그대로 빨리 고쳐야하는 버그이다.)

 

버그 발생 시점에는 이미 dev 브랜치에서는 출시 이후의 작업들이 진행되고 있을 가능성이 크기 때문에 버그 수정 작업을 하기 어렵다.

(버그 수정한 부분만 배포하고 싶은데 다른 기능 개발 코드들이 섞이게된다.)

 

해당 문제를 해결하기 위해 등장한게 hotfix 브랜치이다.

이는 main 브랜치에서 분기되며, 버그 수정 후 main 브랜치와 dev 브랜치로 머지시킨다.

(버그 수정 사항을 dev 브랜치에서도 반영해야 하기 때문이다.)

 

---

마무리

git-flow 흐름을 이해하기 위해 직접 그려본 그림이다.

다시 전체 흐름도를 보자.

브랜치별 역할을 알고 나면 이전보다 이해하기 쉬울 것이다.

 

하지만, git-flow만이 만병 통치약이 아님을 알아두자.

git-flow이외에도 gitlab-flow, github-flow 와 같은 많은 브랜치 전략이 존재한다.

(이들은 git-flow보다는 간결하다.)

 

이러한 전략이 있음을 알아두고, 각 팀에서 자신의 성격에 맞는 전략을 선택 / 혹은 새롭게 만들면 된다.

(참고로 우리 팀도 git-flow 전략을 그대로 따르지 않았다.)

 

---

참고 자료

GitFlow? 들어도 봤고, 쓰고도 있는데...

 

https://nvie.com/posts/a-successful-git-branching-model/

Git 브랜치 전략 (feat. Git Flow, Github Flow)