Kitworks TeamStudy - Git flow

1. Git Flow
박치원
브랜치 전략

2. Git Flow
• 2010년에 Vincent Driessen이 작성한
‘A successful Git Branching model’ 라는 글에서 소개된 브랜치 전략
• master, develop, feature, release, hotfix 5가지 브랜치가 존재

3. 브랜치 종류
• master
• develop
• feature
• release
• hotfix
(배포)
(개발)
(기능)
(QA)
(긴급패치)
: 배포 버전이 관리되는 브랜치 (각 버전을 태깅)
: 다음 배포를 위해 뚝딱뚝딱하는 브랜치
: 기능들을 개발하는 브랜치
: 다음 배포에 포함될 기능들이 다 개발되어 배포를 준비하는 브랜치
: 배포한 버전에서 생기는 문제를 해결하는 브랜치

4. Git Flow의 흐름

6. 개발 진행
• feature는 항상 develop으로부터 생성되고
develop으로만 merge 될 수 있음.
• feature는 작업이 끝난 뒤 삭제됨.

7. 배포 준비, QA
• 개발된 기능들이 develop으로 merge되어
다음 배포를 할 준비가 되면 release 생성
• release에서 버전코드, README 등이 수정
• release에서 발생하는 버그는 release에서 수정되고
수정된 코드가 develop으로 역merge 될 수 있음.

8. 배포
• Release에서 이상이 없으면 master로 merge하고
TAG를 생성해둠.

9. 핫픽스
• 배포한 버전에서 버그가 발생한 경우...

11. 기능 하나를 추가하고
배포를 한다고 가정하면…
1. Feature 생성
2. Develop에 merge
3. Release 생성
4. Master에 merge
5. Develop에 merge
6. Tag 추가
Release에서 배포까지 4단계를 거쳐야한다.

12. Git-flow Extension
귀찮은 과정을 자동으로!

13. Command
• git flow init
• git flow feature start {feature_name}
• git flow feature finish {feature_name}
• git flow release {release_name} [base]
• git flow release finish {release_name}
• git flow hotfix start {hotfix_name} [base]
• git flow hotfix finish {hotfix_name}

14. Source Tree
• 소스트리는 아예 git-flow를 내장하고 있음.

15. 고민해볼 점
Release 브랜치가 꼭 필요할까?
• 수시로 배포가 진행되는 경우
• 안정화 과정이 별로 필요하지 않은 경우

16. Git Flow는 전략들 중 하나일 뿐.
• Git Flow는 하나의 전략일 뿐 꼭 이대로 할 필요는 없다.
• Github Flow, Gitlab Flow 같은 보다 단순한 전략들도 존재.

17. 우리느은
• 규모가 있는 프로젝트는 대부분 적용할 수 있지 않을까?
• 지난 프로젝트를 생각해보면…
• 알아둬서 나쁠 건 없겠다!

18. 끗!

19. 이야기
시간