[Git] Git-flow

Git-flow

Git-flow는 Vincent Driessen가 블로그 글( A successful Git branching model )에서 제안한 branching model을 적용하여 소프트웨어의 소스코드를 관리하고 출시하기 위한 '브랜칭 관리 전략branch management strategy’이다.

 

Vincent의 branching model은 브랜치를 'master - develop-feature - release - hotfix' 5단계로 나눠서 코드를 관리하는 전략이며 항상 유지되는 메인 브랜치들(master, develop)와 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있다.

• master : 기본 브랜치, 제품으로 출시(배포)될 수 있는 브랜치
• develop : 다음 출시 버전을 개발하는 브랜치
• feature : 단위 별로 기능을 개발하는 브랜치
• release : 이번 출시 버전을 준비하는 브랜치
• hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

---

메인 브랜치

처음에는 메인 브랜치인 master와 develop 브랜치만 존재한다.

---

master

깃 사용자라면 누구나 익숙한 기본 브랜치다. 먼저 배포되었거나 배포준비(production-ready)된 코드는 'origin/master'에 두고 관리한다.

• master 브랜치에 '병합' 한다는 것은 새버전을 배포한다는 것을 의미한다. 

---

develop

다음에 배포하기 위해 개발하는 코드는 'origin/develop'에서 관리한다. 프로젝트를 진행하는 개발자들이 함께 보며 업무를 진행하는 브랜치.

• develop 브랜치는 master에서부터 분기된 브랜치이다.
• develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가된다. (hotfixes)

---

보조 브랜치

배포를 준비하고, 이미 배포한 제품이나 서비스의 버그를 빠르게 해결(hotfix) 해야한다. 이 모든 것을 동시에 진행하기 위해서 다양한 브랜치가 필요하다.

---

feature 

새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 기능을 개발하기 위한 분기한 브랜치이다.

• 기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge 됩니다.
• git-flow 이용시 feature/{branch-name} 형식
• 이슈추적을 사용한다면 feature/{issue-number}-{feature-name} 형식
• Ex) feature/1-init-project, feature/2-build-gradle-script-write

---

release

release 브랜치는 실제 배포할 상태가 된 경우에 생성하는 브랜치이다. develop에 이번 버전에 포함되는 모든 기능(feature)이 merge 되었다면 QA를 하기 위해 develop 브랜치에서부터 release 브랜치를 분기한다.

• QA를 진행하면서 발생한 버그들은 release 브랜치에서 수정된다.
• QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge 한다.
• 마지막으로 출시된 master 브랜치에 태그를 추가하여 버전을 기록한다.

---

hotfix

이미 배포 중인 버전에 생긴 버그를 즉각 대응하기 위한 긴급 수정 브랜치이다.

• 치명적인 버그는 즉시 해결해야하기 때문에 문제가 생기면 master 로부터 긴급 수정 브랜치( hotfix )를 생성한다.

• 기본적인 동작방식은 출시 'release'와 비슷하게 해결 후 hotfix 브랜치를 master와 develop 브랜치로 merge 한다.
• 이미 배포한 운영버전에서 발생한 문제를 해결하기 위해 만든다.
• 미리 계획되지 않은 배포를 위한 브랜치다.
• 마지막으로 출시된 master 브랜치에 태그를 추가하여 버전을 기록한다.

---

gitflow 

git-flow 전략을 사용자가 쉽게 접근하고 사용할 수 있도록 확장 기능(명령어)를 제공하는 것이 gitflow이다.

---

gitflow 시작

비어 있는 Git 저장소나 기존 Git 저장소를 gitflow를 사용하기 위해 해당 명령어로 초기화 해야한다.  

$ git flow init

• 명령어를 실행하면 브랜치의 이름을 입력하라는 메시지가 발생하며 직접 지정하거나 엔터를 입력하면 기본 값으로 이름이 정해진다. 
• 명령어를 실행하면 자동으로 master와 develop 브랜치가 생성된다.

How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]	// support : 버전 호환성 문제를 처리하기 위한 브랜치
Version tag prefix? []
Hooks and filters directory? [C:/Users/OK/study/gitflow/.git/hooks]

• $ git flow init -d 옵션을 사용하면 기본값으로 과정을 생략할 수 있다.

---

Feature

Feature 브랜치 생성

$ git flow feature start <branch name>
// $ git checkout -b <branch name> develop와 동일

• feature <branch name>이라는 이름으로 feature 브랜치가 생성되고 자동으로 해당 브랜치로 checkout 된다.

$ git flow feature start some

$ git branch
  develop
* feature/some
  master

---

Feature 브랜치 병합

feature 브랜치에서 작업을 완료하고 해당 명령어를 통해 develop 브랜치에 병합한다.

$ git flow feature finish <branch name>

• feature 브랜치를 삭제하고 develop 브랜치로 checkout 된다.

---

Feature 브랜치를 원격 저장소에 push/pull

• 해당 명령어를 통해 feature 브랜치를 원격 저장소에 push할 수 있다.

$ git flow feature publish <branch name>

• 반대로 원격 저장소에서 feature 브랜치를 가져온다.

$ git flow feature pull origin <branch name>

---

release

release 브랜치 생성

$ git flow release start <version>

• develop branch의 내용을 기반으로 release <version> 의 이름을 갖는 새로운 branch를 하나 생성하여 checkout한다.

---

release 브랜치 병합

release 브랜치에서 작업을 완료하고 해당 명령어를 통해 develop / master 브랜치에 병합한다.

$ git flow release finish v.0.0.1

1. release 브랜치를 master 브랜치에 병합(merge)
2. release 버전으로 태그를 생성한다.(git flow init에서 명시한 Version tag prefix 문자열이 release 버전 앞에 추가되어 태그로 생성된다)
3. release를 develop 브랜치에 재병합(back-merge)
4. release 브랜치 삭제

 

---

참고

https://techblog.woowahan.com/2553/

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

https://gist.github.com/ihoneymon/a28138ee5309c73e94f9