[Git] Git-Flow에 대하여

오늘은 회사에서 새로운 프로젝트를 진행할때 git-flow 브랜치 전략을 적용하기 위해 사전 학습한 내용을 정리하고자 한다.

 

먼저 브랜치 전략이란?

소프트웨어의 상태에 따라 브랜치를 분리하는 전략, git-flow. github-flow, gitlab-flow등이 있다.

 

 

 

그렇다면 git-flow를 쓰면 뭐가 좋은데?

• 기능별로 브랜치를 새로 생성해 작업하므로 각각 병렬적으로 개발할 수 있다!
• feature 브랜치가 존재해 추적이 쉽다!
• 규모가 커질수록 소스코드 관리가 용이하다!

 

git-flow의 흐름을 살펴보자

git-flow를 설명할때 가장 많이 언급되는 흐름도이다.

 

하지만 나는 영어로 되어있어 그런지 잘 이해가 안간다..

이는 밑에 예시를 들면서 설명하겠다.

 

 

 

git-flow에서 각각의 브랜치 역할

 

master - 실제 서비스가 배포되는 서비스로 태그를 달아 버전을 구분한다.(태그를 다는 이유 : 태깅을 통해 이전 버전으로 빠르게 돌아가기 위해)

develop - 개발 브랜치로 feature브랜치들이 완료되면 이 브랜치로 merge된다.

feature - 특정 기능을 추가하기 위한 브랜치로 완료되면 develop으로 merge시켜야 한다.

release - 배포하기 직전에 만드는 브랜치로 일반적으로 기능 추가가 완료되고 품질검사(QA)가 진행된다.

hotfix - 버그가 발견되어 급작스럽게 픽스를 진행해야 할때 사용하는 브랜치로 픽스가 끝나고 나면 develop과 master에 동시에 머지 되어야 한다.

 

 

진행 프로세스 예시(조금의 변형이 있을수 있다.)

 

1. 로그인 기능을 추가하기 위해 develop으로부터 feat/login을 생성한다.

2. 로그인 기능이 완료되면 feat/login을 develop에 merge한다.(merge request를 통해서만 merge - 코드리뷰를 진행하기 위함)

3. 배포 진행시 develop으로부터 release/0.0.1을 생성한다.(이후 QA(배포될수 있는 상태인지)진행)

3-1. release에서 버그 및 수정사항 발생시(ex. 아이디 글자수 제한) release로 부터 새로운 브랜치(fix/id-limit)을 생성한 뒤, 코드 수정 완료후 release에 merge한다.

4. 배포 완료시 release/0.0.1을 develop과 master에 merge한다.(이때 master에는 tag를 달아준다.)

 

+버그 발생(로그인페이지 오류)시 master로부터 hotfix/login-error생성

 

핫픽스 완료후 변경내용을 develop과 master에 merge(이때 master에 hotfix태그 추가)

위의 프로세스대로 브랜치가 관리되는 것이다.

 

 

 

마지막으로 한눈에 보기 쉽게 정리된 그래프 링크를 첨부하며 마치겠습니다!

https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html

 

끝!