Git flow란
Git flow는 소프트웨어의 소스코드를 관리하고 출시하기 위한 branch management strategy(브랜치 관리 전략)입니다.
Vincent Driessen이 2010년에 제시했습니다.
이 외에도 GitHub flow와 GitLab flow도 있습니다.
Git flow - branch
Git flow에는 5가지 종류의 브랜치가 존재합니다.
항상 유지되는 메인 브랜치(master, develop)와 일정 기간 동안만 유지되는 보조 브랜치(feature, release, hotfix)가 있습니다.
* git 확장형 모듈인 git flow 명령어로 생성시 support(버전 호환성 문제를 위한 브랜치), bugfix(버그를 고치기 위한 브랜치)가 추가된다.
- master : 제품으로 출시될 수 있는 브랜치
- develop : 다음 출시 버전을 개발하는 브랜치
- feature : 기능을 개발하는 브랜치
- release : 이번 출시 버전을 준비하는 브랜치
- hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
위 그림은 일반적인 개발 시나리오입니다.
-
처음은
master브랜치에서 시작을 합니다. -
동일한 브랜치를
develop으로도 생성합니다. 개발자들은develop브랜치에서 개발을 진행합니다. -
개발을 진행하다가 회원가입, 장바구니 등의 기능 구현이 필요할 경우 A개발자는
develop브랜치에서feature브랜치를 하나 생성해서 회원가입 기능을 구현하고 B개발자도develop브랜치에서feature브랜치를 하나 생성해서 장바구니 기능을 구현합니다.
이때feature의브랜치 명명 규칙에 따라 다른 브랜치로 관리하도록 합니다. -
완료된
feature브랜치는 검토를 거쳐 다시develop브랜치에 합칩니다.(Merge) -
모든 기능이 구현되면
develop브랜치를release브랜치로 만듭니다. 그리고 QA(품질검사)를 하면서 보완점을 보완하고 해당 브랜치에서 버그 픽스를 진행합니다. -
모든 것이 완료되면 이제
release브랜치를 메인 브랜치인master와develop으로 보냅니다.master브랜치에서 버전추가를 위해 태그를 하나 생성하고 배포를 합니다. -
배포를 했는데 미처 발견하지 못한 버그가 있을 경우
hotfixes브랜치를 만들어 긴급 수정 후 6번의 과정을 진행하여 수정 배포를 진행합니다.
메인 브랜치
/** 저장소 생성 **/
$ git clone <remote repository URL>
// OR
$ git init
$ git remote add origin [중앙 remote repository URL]
$ git pull origin master
/** 브랜치 생성 **/
// 빈 develop 브랜치를 만들어서 중앙 저장소로 push
$ git branch develop
$ git push origin developgit flow 모듈 사용
// git flow branch 생성(-d 옵션시 default 설정)
$ git flow initmaster branch
배포 이력을 관리하기 위해 사용합니다. 즉, origin/master branch의 HEAD는 항상 배포 가능한 상태로 관리합니다.
release 또는 develop에서 안정적인 지점에 도달하면 병합한 후 버전을 태그로 지정하여 배포 가능한 상태로 만듭니다.
develop branch
개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합칩니다.
origin/develop branch의 HEAD는 항상 다음 버전에 최신으로 전달될 변경 사항이 있는 상태를 반영하는 주요 분기입니다.
보조 브랜치
보조 브랜치로 팀 구성원 간의 병렬 개발을 지원하고, 기능 추적을 용이하게 하고, 프로덕션 릴리스를 준비하고, 라이브 프로덕션 문제를 신속하게 수정하는 데 도움을 줍니다.
기본 분기와 달리 이 분기는 결국 제거되기 때문에 수명이 항상 제한됩니다.
feature branch
브랜치가 나오는 곳(checkout): develop
브랜치가 들어가는 곳(merge): develop
브랜치명 규칙: master, develop, release-*, hotfix-*를 제외한 모든 것
새로운 기능을 추가하는 브랜치.
일반적으로 로컬 레포지토리에만 생성해 develop으로 merge를 합니다.
여기서 merge를 할 때, --no-ff 옵션을 이용하여 브런치에서 머지가 되었음을 git 기록에 남겨두도록 합니다.
// 'feature' 브랜치(feature/login)를 'develop' 브랜치에서 분기
$ git checkout -b feature/login develop
/** 새로운 기능에 대한 작업 수행 **/
// 'develop' 브랜치로 이동
$ git checkout develop
// 'develop' 브랜치에 'feature/login' 브랜치 내용을 병합
$ git merge --no-ff feature/login
// `feature/login` 브랜치 삭제
$ git branch -d feature/login
// 'develop' 브랜치를 원격 중앙 저장소에 올린다.
$ git push origin developcheckout -b 옵션: 현재브랜치에서 새로운 브랜치 생성하고 갈아탐
merge --no-ff 옵션: --no-ff (non fast-forward) 옵션은 merge 대상과 fast-forward 관계여도 강제로 merge commit을 생성하고 병합합니다. 이를 통해develop의 과거 존재에 대한 정보 손실을 방지하고 기능을 함께 추가한 모든 커밋을 함께 그룹화합니다.
/** Git Flow 사용 **/
// develop 브랜치를 기반으로 feature 브랜치 생성, 이 후 자동으로 생성된 feature 브랜치로 checkout
// 생성된 feature 브랜치는 'feature/<name>' 의 이름을 갖는다
$ git flow feature start <name>
/** 새로운 기능에 대한 작업 수행 **/
// develop 브랜치로 checkout, develop으로 merge, feature 브랜치 삭제
$ git flow feature finish <name>git flow 모듈에서 push와 pull의 경우 다음과 같이 한다
$ git flow feature publish <feature name> $ git flow feature pull origin <feature name>
release branch
브랜치가 나오는 곳(checkout): develop
브랜치가 들어가는 곳(merge): develop, master
브랜치명 규칙: release-*
이번 출시 버전을 준비하는 브랜치.
배포를 위한 전용 브랜치를 사용함으로써 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능 개발을 계속할 수 있습니다.
새 릴리스 브랜치로 분기하는 순간은 develop의 개발이 다음 버전에 원하는 상태를 충족하는 시점입니다.
// release 브랜치(버전 1.2)를 'develop' 브랜치에서 분기
$ git checkout -b release-1.2 develop
/** 배포 사이클 수행 **/
// 배포 가능한 상태가 되면 'master' 브랜치로 이동
$ git checkout master
// 'master' 브랜치에 release-1.2 브랜치 내용을 병합
$ git merge --no-ff release-1.2
// 병합한 커밋에 Release 버전 태그 부여
$ git tag -a 1.2
/** 'release' 브랜치의 변경 사항을 'develop' 브랜치에도 적용 **/
// 'develop' 브랜치로 이동
$ git checkout develop
// 'develop' 브랜치에 release-1.2 브랜치 내용을 병합
$ git merge --no-ff release-1.2
// release-1.2에 해당하는 브랜치를 삭제
$ git branch -d release-1.2/** Git Flow 사용 **/
// develop 브랜치를 기반으로 release 브랜치 생성, 이 후 자동으로 생성된 release 브랜치로 checkout
// 생성된 release 브랜치는 'release/<version>' 의 이름을 갖는다
$ git flow release start <version>
/** 협업시 publish, pull 활용 **/
// release 브랜치를 master 브랜치에 병합하고 release 버전을 태그로 생성한다.
// 이 때, init 에서 설정한 Version tag prefix 문자열이 release버전 앞에 추가되어 태그로 생성된다.
// release 브랜치를 develop 브랜치에 병합, release 브랜치를 삭제한다.
$ git flow release publish <version>
// 새로운 릴리즈가 포함된 master 브랜치를 원격 저장소에 태그들과 함께 push하면 된다.
$ git push --tagshotfix branch
브랜치가 나오는 곳(checkout): master
브랜치가 들어가는 곳(merge): develop, master
브랜치명 규칙: hotfix-*
출시 버전에서 발생한 버그를 수정 하는 브랜치.
다음 배포를 위해 개발하던 작업 내용에 전혀 영향을 주지 않고, 출시중인 버전의 버그를 고치도록 한다.
// hotfix 브랜치(hotfix-1.2.1)를 'master' 브랜치에서 분기
$ git checkout -b hotfix-1.2.1 master
/** 문제 수정 **/
// 'master' 브랜치로 이동
$ git checkout master
// 'master' 브랜치에 hotfix-1.2.1 브랜치 내용을 병합(merge)한다.
$ git merge --no-ff hotfix-1.2.1
// 병합한 커밋에 새로운 버전 이름으로 태그를 부여한다.
$ git tag -a 1.2.1
/* 'hotfix' 브랜치의 변경 사항을 'develop' 브랜치에도 적용 */
// 'develop' 브랜치로 이동한다.
$ git checkout develop
// 'develop' 브랜치에 hotfix-1.2.1 브랜치 내용을 병합(merge)한다.
$ git merge --no-ff hotfix-1.2.1/** Git Flow 사용 **/
// 'hotfix/<version>' 브랜치 생성 및 checkout
$ git flow hotfix start <version>
// hotfix 브랜치를 master 브랜치로 병합, hotfix 버전을 태그로 생성,
// hotfix 브랜치를 develop 브랜치에 병합, hotfix 브랜치 삭제
$ git flow hotfix finish <version>
// 원격 저장소에 태그 저장
$ git push --tags레퍼런스
