3 min to read

git-flow

협업을 위한 브랜치 전략

Featured image

git-flow는 Vincent Driessen가 2010년에 고안한 브랜치 모델이다. 때문에 빈센트도 git-flow가 정답은 아니라고 말하며 오히려 GitHub flow와 같은 더 단순화 된 workflow를 추천한다. 그럼에도 불구하고 많은 곳에서 git flow를 사용하고 있기에 정리해보았다.

# # #

브랜치의 종류

git-model.png

메인 브랜치

사라져서는 안되는 브랜치

master

제품(production)으로 출시될 수 있는 브랜치이며 production 상태와 일치하는 브랜치

production 상태란 우리가 흔히 말하는 현재 서비스되고 있는 라이브 상태

develop

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

feature(기능) 개발을 위한 브랜치로, 모든 기능이 추가되고 버그가 수정되어 배포가 가능한 상태를 만든다.

main-branches.png

qa

다음 출시 버전을 테스트하는 브랜치

develop에서 완성된 기능들을 QA팀의 지원을 받아 통합 테스트 환경에서 실제 테스트를 진행하는 브랜치. 개발 시에 확인 못한 이슈들을 해당 브랜치에서 검증한다. 참고로 git flow 상에선 존재하지 않는 브랜치이다.
# # #

보조 브랜치

필요에 따라 생성, 삭제가 가능한 브랜치

feature/*

기능을 개발하는 브랜치

버그 수정이 필요할 때마다 develop(또는 qa브랜치) 분기한다. feature 브랜치의 작업은 기본 적으로 공유할 필요가 없기 때문에 자신의 로컬 저장소에서 관리한다.

이따금 로컬 저장소가 삭제되는 경우(가령 컴퓨터 고장)나 작업 내역이 길어질 경우 원격 저장소에 저장해도 무방하다.

  1. develop 브랜치로부터 새로운 기능에 대한 feature 브랜치를 생성한다.
  2. 만들어진 브랜치에서 작업을 수행한다.
  3. 작업이 끝나면 develop 브랜치로 병합(merge) 한다.
  4. 병합된 feature 브랜치는 삭제한다.

브랜치 이름은 기본 적으로 feature/{JIRA이슈} 지정한다. ex) feature/MODP-1234 JIRA를 사용하지 않는다면 기능 이름을 추가한다. ex) feature/login

feature 브랜치의 merge 방법

merge-without-ff.png

브랜치를 merge하는 방법은 기본 방식인 fast-forward 방식과, no fast-forward(--no-ff) 두가지로 볼 수 있다.

기본 적으로 git flow는 merge 기반의 솔루션이기 때문에 —no-ff 방식을 사용한다. 다만 이 경우 흔히 수많은 이력들이 생겨버리는 merge hell이 발생할 수 있다. rebase를 사용하면 마치 fast-forward를 사용한 것 처럼 이력을 통합 할 수 있다. 장단점이 있으니 프로젝트 성격에 맞게 사용하자.

브랜치 통합하기: https://backlog.com/git-tutorial/kr/stepup/stepup1_4.html

release/*

출시 버전을 배포를 위해 최종 수정을 하는 브랜치

배포를 위한 전용 브랜치를 사용함으로써 해당 배포를 준비하는 동안 develop에서 새로운 다음 배포를 위한 기능 개발을 진행할 수 있다.

  1. develop 브랜치에서 배포할 수 있는 수준의 기능이 완료되면, develop 브랜치로 부터 release 브랜치를 생성한다.
  2. release 브랜치를 qa 브랜치에 병합(merge)하여 qa 테스트를 진행한다.
  3. 만들어진 브랜치에서 버그가 발견되면 feature 브랜치를 만들어 수정을 반복한다.
  4. 모든 기능들이 정상 동작한다고 판단되면 master 브랜치에 병합한다. 배포를 준비하는 동안 기능들이 변경 또는 버그 수정이 일어났을 수 있기 때문에 develop 브랜치에도 병합한다.
  5. 병합된 release 브랜치는 삭제한다.

브랜치 이름은 release/{v버전} 으로 진행한다. ex) release/v1.2.1

hotfix/*

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

배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우 master 브랜치에서 분기하는 브랜치이다. 다음 릴리즈 주기를 기다리지 않고, 문제 상황에 대처할 수 있다.

  1. master 브랜치로부터 hotfix 브랜치를 생성한다.
  2. 문제가 되는 부분을 수정한다.
  3. master 브랜치에 병합 후 배포한다.
  4. develp 브랜치에도 병합을 진행한다.
  5. 병합된 hotfix 브랜치는 삭제한다.

브랜치 이름은 hotfix/{v버전} 으로 진행한다. ex) hotfix/v1.2.1

hotfix-branches.png

# # #

어떻게 사용할 것인가?

슬라이드1.png

위에 나온 설명을 토대로 git flow를 프로젝에 적용해보았다. qa 브랜치가 추가된 점이 약간 다르다. 직정 경험해보니 release 브랜치가 핵심 요소라고 느꼈다. 라이브 서비스 후 패치 간격이 2주 정도로 매우 짧았는데, 개발이 완료된 기능(예를 들자면 v1.0.1)을 qa 브랜치에 배포하여 테스트 도중 다음 배포를 위한 기능(v1.0.2)을 같이 테스트해야 하는 시점이 존재했다. release 브랜치로 나누니 이슈가 생겨도 해당 브랜치에서 수정 후 반영하고 모든 이슈가 종료되면 해당 브랜치만 master로 병합하여 깔끔했다.

정답은 없다. git-flow를 고안한 빈센트의 말을 인용하자면 자신의 상황에 맞게 고려하고 스스로 결정하길 바란다.

# # #

출처