Git Flow
1. Git Flow 란?
- Vincent Driessen 이 사용한 성공적인 Git branching model
2. 주요 브랜치
master branch
- 먼저 배포했거나 곧 배포할 코드를 관리하기 위한 브랜치
- master branch에 커밋하는것은 새로운 버전을 배포하는 행위로 엄격하게 이루어 져야한다
develop branch
- 배포할 것을 개발하는 코드를 관리하기 위한 브랜치
- develop branch의 코드가 안정되고 배포할 준비가 되면 master로 merge하고 배포 버전으로 태그를 단다
3. 보조 브랜치
feature branch
갈라져 나온 브랜치: develop
다시 merge할 브랜치: develop
브랜치 이름 규칙: master, develop, release-*, hotfix-*를 제외한 것-
topic branch라고도 부르며 배포할 기능에 대해 개발하기위한 브랜치이다
-
기능 구현이 완료되면 develop 브랜치로 merge한다
-
다음 배포에 확실히 넣을 거라고 판단될 때 merge하고 결과가 실망스러우면 버린다
-
일반적으로 개발자의 local환경에서 생성 및 관리된다
-
--no--ff옵션을 주어 항상 merge 커밋을 만들어 merge 한다- fast-forward 하더라도 merge history를 남겨 기록을 추후에도 쉽게 확인할 수 있다
- 추가한 feature를 되돌리고 싶을 때 merge 커밋을 남기면 쉽게 revert 지점을 찾을 수 있다
release branch
갈라져 나온 브랜치: develop
다시 merge할 브랜치: develop, master
브랜치 이름 규칙: release-*- 제품 배포를 준비하는 브랜치이다
- 배포하는 데 필요한 버전 넘버, 빌드 일정 등의 메타데이터를 준비하고 버그를 잡는다
- develop과 release를 분리하므로 develop branch에서는 다음 배포를 위한 기능구현에 집중할 수 있다
- release branch를 만든다는것은 배포 버전을 부여하겠다는 것을 의미한다
- 발생한 버그는 develop이 아닌 이 브랜치에서 해결하며 새로운 기능은 이 브랜치에 추가하지 않아야 한다
- 배포할 상태가 되면 master branch로 merge 하고 master가 가리키는 커밋을 가리키게한다
hotfix branch
갈라져 나온 브랜치: master
다시 merge할 브랜치: develop, master
브랜치 이름 규칙: hotfix-*- 이미 배포한 운영 버전에 생긴 문제를 해결하기 위해 만든다
- 운영 버전에 생긴 치명적인 버그는 즉시 해결해야 하기 때문에 문제가 생기면 master branch에 만들어 둔 tag로 부터 hotfix 브랜치를 만든다
- 만든 브랜치에 버전넘버를 수정하고 버그를 해결한 후 한두개의 커밋으로 해결하는것이 좋다
- 버그를 잡았다면 master에 merge하고 버그 수정이 모두 적용되어야 하므로 develop 브랜치에도 merge해야한다.
- release 브랜치가 남아있다면 (보통 배포완료 후 삭제하기 때문에) release 브랜치에도 merge하여 버그를 수정시켜야 한다.
