git flow를 공부하고 있어요

git은 버전관리 프로그램으로써 실무에서 사용하다보면 효율적인 업무를 위해 브랙치전략을 바꾸거나 수립하게 되는일이 있을거에요

그래서 git을 사용하는 엔지니어로써 git flow를 어떻게 사용하는것인지 알아보게 되었어요

시작하며..

배달의민족 기술블로그의 사용기를 살펴보며, git flow 모델을 사용하게된 동기에 대한 필요성을 이해해 보았어요
도입을 결정한 이유는 다음과 같다고 합니다


배달의민족 앱 개발자가 2~3명에서 5명으로 늘어나면서, 이 5명이 모두 기능을 개발하는 것은 비효율적이었다고 해요. 개발 기간이 3주 이상으로 오래 걸리는 작업들이 많아지기 시작한 이유도 있었다고 합니다. 아마도 효율적인 업무분배를 위해서 가장 적합한 모델로 판정하여 Git-flow를 선택하였고, 기존에 git을 사용하던 개발자들이었으므로 큰 어려움없이 브랜치전략을 바꿀 수 있었던것 같아요.

Git Repository 구성 및 워크플로우

Upstream Repository : 개발자들이 공유하는 저장소로 최신 소스코드가 저장되어 있는 원격 저장소
Origin Repository : Upstream Repository를 Fork한 원격 개인 저장소
Local Repository : 내 컴퓨터에 저장되어 있는 개인 저장소

위 그림에서의 플로우를 그려보면, 개인이 Local Repository에서 작업을 완료했을 때, 해당 브랜치을 Origin Repository에 push하고, push한 브랜치를 Upstream Repository로 Pull Request를 요청하고, 검사를 거친 후 merge 합니다. 새로운 작업을 할 때는 항상 Local Repository에서 Upstream Repository를 pull하여 최신 소스코드가 적용되어 있는 환경에서 작업합니다.


위와 같은 플로우로 작업하는데에는 한 가지 이유가 있었다고 하는데요. 그 이유는 개발자들의 실험정신(?)을 펼치기 위해서라고 합니다. 모두가 공유하고 있는 Upstream Repository는 무결성을 유지한채로, fork한 개인 Remote Repository와 Local Repository에서 공유를 하지않으니 개인의 저장소에서 안심하고 부담없이 기능개발에 대한 실험을 해볼 수 있게 되는것이지요

Git-flow를 구성하는 branch의 역할

Git-flow 워크플로우에는 5가지 종류의 브랜치가 존재하는데, 항상 유지되는 메인 브랜치(master, develop)와 메인 브랜치에서 분기하여 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)로 구성되요

아래 그림은 브랜치의 흐름을 나타내는 대표적인 그림이에요

일반적인 워크플로우를 살펴보겠습니다
처음에는 메인 브랜치인 master와 develop 브랜치가 존재합니다. 두 브랜치는 항상 유지되는 브랜치입니다. develop 브랜치에서 기능 추가가 있는 경우 develop 브랜치에서 feature 브랜치로 분기합니다. 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge 됩니다. develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치에서부터 release 브랜치를 생성합니다. QA를 진행하면서 발생한 버그들은 release 브랜치에서 수정됩니다. QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge 합니다. 마지막으로 출시된 master 브랜치에서 버전 태그를 추가합니다.

1. Master Branch

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

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

 

2. Develop Branch

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

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

 

3. Feature branch

기능을 개발하는 브랜치

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

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

[feature/기능요약] 형식을 추천 EX) feature/login

feature의 branch생성 및 종료 과정

// feature 브랜치(feature/login)를 'develop' 브랜치('master' 브랜치에서 따는 것이 아니다!)에서 분기
$ git checkout -b feature/login develop

/* ~ 새로운 기능에 대한 작업 수행 ~ */

/* feature 브랜치에서 모든 작업이 끝나면 */
// 'develop' 브랜치로 이동한다.
$ git checkout develop

// 'develop' 브랜치에 feature/login 브랜치 내용을 병합(merge)한다.
# --no-ff 옵션: 아래에 추가 설명
$ git merge --no-ff feature/login

// -d 옵션: feature/login에 해당하는 브랜치를 삭제한다.
$ git branch -d feature/login

// 'develop' 브랜치를 원격 중앙 저장소에 올린다.
$ git push origin develop

 

--no-ff 옵션
- 새로운 커밋 객체를 만들어 ‘develop’ 브랜치에 merge 한다.
- 이것은 ‘feature’ 브랜치에 존재하는 커밋 이력을 모두 합쳐서 하나의 새로운 커밋 객체를 만들어 ‘develop’ 브랜치로 병합(merge)하는 것이다.

4. Release Branch

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

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

 

1. ‘develop’ 브랜치에서 배포할 수 있는 수준의 기능이 모이면 또는 정해진 배포 일정이 되면, release 브랜치를 분기한다.
    - release 브랜치를 만드는 순간부터 배포 사이클이 시작된다.
    - release 브랜치에서는 배포를 위한 최종적인 버그 수정, 문서 추가 등 릴리스와 직접적으로 관련된 작업을 수행한다.
    - 직접적으로 관련된 작업들을 제외하고는 release 브랜치에 새로운 기능을 추가로 병합(merge)하지 않는다.
2. ‘release’ 브랜치에서 배포 가능한 상태가 되면(배포 준비가 완료되면),
    - 배포 가능한 상태: 새로운 기능을 포함한 상태로 모든 기능이 정상적으로 동작 하는 상태
    - ‘master’ 브랜치에 병합한다. (이때, 병합한 커밋에 Release 버전 태그를 부여!)
    - 배포를 준비하는 동안 release 브랜치가 변경되었을 수 있으므로 배포 완료 후 ‘develop’ 브랜치에도 병합한다.
이때, 다음 번 배포(Release)를 위한 개발 작업은 ‘develop’ 브랜치에서 계속 진행해 나간다.

 

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

 

release의 branch생성 및 종료 과정

// release 브랜치(release-1.2)를 'develop' 브랜치('master' 브랜치에서 따는 것이 아니다!)에서 분기
$ git checkout -b release-1.2 develop

/* ~ 배포 사이클이 시작 ~ */

/* release 브랜치에서 배포 가능한 상태가 되면 */
// 'master' 브랜치로 이동한다.
$ git checkout master

// 'master' 브랜치에 release-1.2 브랜치 내용을 병합(merge)한다.
# --no-ff 옵션: 위의 추가 설명 참고
$ git merge --no-ff release-1.2

// 병합한 커밋에 Release 버전 태그를 부여한다.
$ git tag -a 1.2

/* 'release' 브랜치의 변경 사항을 'develop' 브랜치에도 적용 */
// 'develop' 브랜치로 이동한다.
$ git checkout develop

// 'develop' 브랜치에 release-1.2 브랜치 내용을 병합(merge)한다.
$ git merge --no-ff release-1.2

// -d 옵션: release-1.2에 해당하는 브랜치를 삭제한다.
$ git branch -d release-1.2

 

 

5. Hotfix Branch

출시 버전에서 발생한 버그를 수정 하는 브랜치

배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, ‘master’ 브랜치에서 분기하는 브랜치이다. ‘develop’ 브랜치에서 문제가 되는 부분을 수정하여 배포 가능한 버전을 만들기에는 시간도 많이 소요되고 안정성을 보장하기도 어려우므로 바로 배포가 가능한 ‘master’ 브랜치에서 직접 브랜치를 만들어 필요한 부분만을 수정한 후 다시 ‘master’브랜치에 병합하여 이를 배포해야 하는 것이다.

1. 배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우,
   - ‘master’ 브랜치에서 hotfix 브랜치를 분기한다. (‘hotfix’ 브랜치만 master에서 바로 딸 수 있다.)
2. 문제가 되는 부분만을 빠르게 수정한다.
   - 다시 ‘master’ 브랜치에 병합(merge)하여 이를 안정적으로 다시 배포한다.
   - 새로운 버전 이름으로 태그를 매긴다.
3. hotfix 브랜치에서의 변경 사항은 ‘develop’ 브랜치에도 병합(merge)한다.

 

버그 수정만을 위한 ‘hotfix’ 브랜치를 따로 만들었기 때문에, 다음 배포를 위해 개발하던 작업 내용에 전혀 영향을 주지 않는다. ‘hotfix’ 브랜치는 master 브랜치를 부모로 하는 임시 브랜치라고 생각하면 된다.

 

- hotfix 브랜치 이름 정하기
   [hotfix-* ] 형식을 추천 EX) hotfix-1.2.1

hotfix의 branch생성 및 종료 과정

// release 브랜치(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

 

Branch의 전체 흐름

참고

- [A successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model)

- [우린 git flow를 사용하고 있어요](https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html)

- [Git 브랜치의 종류 및 사용법(5가지)](https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html)