GitFlow

mvc패턴이 있듯이 git branch운영에 많이 사용되는 방법론이다.
즉, 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 전략이다.

GitFlow 구성 5가지

1.Master

제품으로 출시될 수 있는 브랜치
즉, 배포 가능한 상태만 관리한다. 커밋할 때에는 태그를 사용하여 배포번호를 기록한다.

앞에서 설명한 통합 브랜치를 뜻한다.

2.Develop

다음 출시 버전을 개발하는 브랜치
기능 개발을 위한 브랜치들을 병합하기 위해 사용. 즉, 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 ‘master’ 브랜치에 병합(merge)한다.
평소에는 이 브랜치를 기반으로 개발을 진행한다.

앞에서 설명한 토픽 브랜치를 뜻한다.

3.Feature

기능을 개발하는 브랜치
feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 develop 브랜치로부터 분기한다.
feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에, 자신의 로컬 저장소에서 관리한다.
개발이 완료되면 ‘develop’ 브랜치로 병합(merge)하여 다른 사람들과 공유한다.

4.Release

배포 버전을 준비하는 브랜치

1. develop브랜치에서 배포할 수준의 기능 개발이 완료되면, develop에서 release브랜치를 분기한다.
   • 분기 순간부터 배포 사이클이 시작된다.
   • 관례적으로 브랜치 이름 앞에 "release-"를 붙인다.
   • release브랜치에서는 배포를 위한 "버그 수정, 문서 추가"등 release와 직접적으로 관련된 작업만 수행한다.
   • 다음 릴리즈 개발 작업은 "develop" 브랜치에서 계속 진행해 나가면 된다.
2. release브랜치에서 배포 가능한 상태가 되면 master브랜치에 병합된다. 또한 develop브랜치에도 병합 적용해 주어야 한다.
   • 이때, 병합한 커밋에 release 버전 태그를 단다.

[release branch 장점]
배포를 위한 전용 브랜치를 사용함으로써 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능 개발을 계속할 수 있다. 즉, 딱딱 끊어지는 개발 단계를 정의하기에 좋다.

예를 들어, 이번 주에 버전 1.3 배포를 목표로 한다!라고 팀 구성원들과 쉽게 소통하고 합의할 수 있다.

[릴리즈 과정 예]

1. git checkout -b release-1.2 develop
   • develop 브랜치에서 release-1.2브랜치를 딴다.
2. 배포 사이클 종료
   • 버그 수정, 주석 추가 등등
3. git checkout master
4. git merge --no-ff release-1.2
   • 아래에 --no-ff옵션 설명 참고
5. git tag -a 1.2
   • 병합한 커밋에 release 버전 태그를 부여
6. git checkout develop
   • release 브랜치의 변경사항을 develop에도 적용
7. git merge --no-ff release-1.2
8. git branch -d release-1.2
   • release-1.2에 해당하는 브랜치를 삭제한다.

[--no-ff옵션]

• 새로운 커밋 객체를 만들어 develop브랜치에 merge한다.
• 이것은 feature브랜치에 존재하는 커밋 이력을 모두 통합하여 하나의 커밋 객체를 만들어 develop브랜치에 병합하는 것이다.
• 

[release 브랜치 네이밍]

• release-RB_*,release-*,release/*처럼 짓는 것이 일반적
• release-*추천

## 5\. Hotfix

배포 버전에서 발생한 버그를 수정 하는 브랜치
배포한 버전에서 긴급하게 수정을 해야 할 필요가 있을 경우, master브랜치에서 분기하는 브랜치다.
develop브랜치에서 문제가 되는 부분을 수정하여 배포 가능한 버전을 만들기에는 시간도 많이 소요되고 안정성을 보장하기 어렵다. 그래서 바로 배포가 가능한 master브랜치에서 직접 브랜치를 만들어 필요한 부분만 수정한 후 다시 master브랜치에 병합하여 이를 배포한다.
관례적으로 브랜치 이름 앞에 "hotfix-"를 붙인다.

정리하자면, release는 develop에서 분기한 임시 브랜치이고, hotfix는 master에서 분기한 임시 브랜치이며 release 이후에 생성된 브랜치이다. 활용하는 방법은 동일하다.

전체 git-flow

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

Summary

1. 신규 기능 개발은 feature,develop에서
2. 라이브 서버로 배포는 develop,release,master에서
3. 배포 후 관리는 develop,hotfix,master에서
   이뤄진다.