[git] Gitflow Workflow

Gitflow Workflow

Gitflow Workflow는 코드 릴리스를 중심으로 브랜치가 구성됩니다.

그 외 중앙 저장소를 사용하던가 로컬 브랜치에서 작업하고 중앙 저장소에 push하는 것은 동일합니다.

그럼, 브랜치별 역할을 알아봅시다.

1. master Branch

제품으로 출시될 수 있는 브랜치

배포(Release) 이력을 관리하기 위해 사용합니다. 즉, 이 브랜치는 배포 가능한 상태만을 관리합니다.

2. delelop 브랜치

다음 출시 버전을 개발하는 브랜치

기능 개발을 위한 브랜치들을 병합하기 위해 사용합니다. 즉, 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 ‘master’ 브랜치에 병합(merge)합니다.

평소에는 이 브랜치를 기반으로 개발을 진행합니다.

3. feature Branch

기능을 개발하는 브랜치

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

• Feature 브랜치에서의 개발 과정

1. ‘develop’ 브랜치에서 새로운 기능에 대한 feature 브랜치를 분기합니다.
2. 새로운 기능에 대한 작업 수행합니다.
3. 작업이 끝나면 ‘develop’ 브랜치로 병합(merge)합니다.
4. 더 이상 필요하지 않은 feature 브랜치는 삭제합니다.
5. 새로운 기능에 대한 ‘feature’ 브랜치를 중앙 원격 저장소에 올립니다.(push)

• feature 브랜치 이름 정하기
  • master, develop, release-(RB_), or hotfix- 제외
  • [feature/기능요약] 형식을 추천 EX) feature/login

4. release Branch

이번 출시 버전을 준비하는 브랜치

develop 브랜치에 릴리스를 할 수 있는 수준만큼 기능이 모이면(또는 정해진 릴리스 일정이 되면), develop 브랜치를 기준으로 릴리스를 위한 브랜치를 생성. release 브랜치는 버그 수정, 문서 추가 등 릴리스와 직접적으로 관련된 작업 외에 새로운 기능을 추가 병합하지 않음. 릴리스 준비가 완료되면 master 브랜치에 병합하고 버전 태그를 부여 함. 릴리스를 준비하는 동안 develop 브랜치가 변경되었을 수 있으므로 develop 브랜치와 병합.

(릴리스 브랜치는 release- 또는 release/처럼 이름 짓는 것이 일반적인 관례)

배포를 위한 전용 브랜치를 사용함으로써 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능 개발을 계속할 수 있습니다. 즉, 딱딱 끊어지는 개발 단계를 정의하기에 아주 좋다.예를 들어, ‘이번 주에 버전 1.3 배포를 목표로 한다!’라고 팀 구성원들과 쉽게 소통하고 합의할 수 있다는 말입니다.

1. ‘develop’ 브랜치에서 배포할 수 있는 수준의 기능이 모이면 또는 정해진 배포 일정이 되면, release 브랜치를 분기한다.
   • release 브랜치를 만드는 순간부터 배포 사이클이 시작된다.
   • release 브랜치에서는 배포를 위한 최종적인 버그 수정, 문서 추가 등 릴리스와 직접적으로 관련된 작업을 수행한다.
   • 직접적으로 관련된 작업들을 제외하고는 release 브랜치에 새로운 기능을 추가로 병합(merge)하지 않는다.
2. ‘release’ 브랜치에서 배포 가능한 상태가 되면(배포 준비가 완료되면),
   • 배포 가능한 상태: 새로운 기능을 포함한 상태로 모든 기능이 정상적으로 동작 하는 상태

     1. ‘master’ 브랜치에 병합한다. (이때, 병합한 커밋에 Release 버전 태그를 부여!)

     2. 배포를 준비하는 동안 release 브랜치가 변경되었을 수 있으므로 배포 완료 후 ‘develop’ 브랜치에도 병합한다.

        이때, 다음 번 배포(Release)를 위한 개발 작업은 ‘develop’ 브랜치에서 계속 진행해 나간다.

• release 브랜치 이름 정하기
  • release-RB_ 또는 release- 또는 release/* 처럼 이름 짓는 것이 일반적인 관례
  • [release-* ] 형식을 추천 EX) release-1.2