Git-flow

[Git-flow란?]

Git이 활성화되던 2010년도 정도에 Vincent Driessen이라는 사람이 만든 Git 기반의 브랜치 관리 전략이다. 

Git-flow는 완벽한 개발 방법론이 아닌 각자의 개발환경에 맞춰 변형해서 사용하는 것이 좋다고 언급하였다. 

 

[Git-flow 사용 이유]

프로젝트 규모가 작거나 혼자서 개발을 할 경우 master 브랜치에서 그냥 작업해도 된다. 

하지만 규모가 커질 경우 누군가는 하루종일 conflict를 해결해야하며, 이슈가 발생했을 때 개발한 코드를 롤백하는 등의 이슈가 있다.

이 같은 문제를 최소화하고 형상 관리를 효율적으로 하기 위해 생겨난 전략 중에 하나라고 생각하면 된다. 

 

[Git-flow Branch 종류]

• master: 제품으로 출시될 수 있는 브랜치
• develop: 개발 브랜치
• feature: 기능 개발 브랜치
• release: 이번 출시 버전 브랜치
• hotfix: 버그 수정 브랜치 

Git-flow

 

예시 : A는 게시판에 필터기능을 추가하고, B는 게시글에 댓글 기능을 추가한다

1. dev 브랜치에서 A, B가 각각 feature 브랜치를 생성한다.
2. 개발이 완료되면 각자 feature 브랜치에 커밋한다.
3. feature 브랜치에서 dev 브랜치로 PR요청한다.  
4. release 브랜치에서 QA를 진행하기 위해 머지한다.
5. QA가 완료되었다면 master, dev에 머지를 진행한다. 

 

예시 : 운영 서버에서 버그가 발생했다 (hotfix)

1. master 브랜치에서 바로 hotfix 브랜치를 생성한다.
2. 버그 수정 후 master 브랜치에 머지를 진행하고, dev, release에도 머지를 진행한다. 

 

[예시 시나리오]

1. dev에서 각자 feature로 브랜치를 생성한다. (featrue/{task번호}-{작업명}-{본인아이디})
2. 각자 작업을 진행한다. 
3. 작업이 완료되면 dev브랜치로 PR을 요청하고 머지한다. 
4. 각자 작업들이 모두 dev에 머지된다면 릴리즈 브랜치에 머지한다. 
5. QA를 진행한다.
6. QA를 진행하다가 수정사항이 또 발생할 경우 각자 feature 브랜치에 작업한다.
7. feature 브랜치에 작업 후 dev 브랜치로 PR을 요청하고 머지한다.
8. 릴리즈 브랜치에 머지한다. 
9. QA가 완료되면 master에 배포한다. 

 

[참조]

https://gist.github.com/ihoneymon/a28138ee5309c73e94f9

git 을 기반으로 git-flow를 사용하여 애플리케이션 배포버전을 관리하자.