git-flow 전략

Git-flow는 총 5가지 브랜치를 사용하고 운영한다.

  • master 브랜치 : 기준이 되는 브랜치로 제품을 배포하는 브랜치이다.
  • develop 브랜치 : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합(Merge)한다.
  • feature 브랜치 : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합(Merge)한다.
  • release 브랜치 : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치이다.
  • hotfix 브랜치 : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치이다.

! 여기서 핵심이 되는 브랜치는 master 브랜치와 develop 브랜치이다. 나머지 브랜치는 필요에 의해 운영되는 브랜치라고 생각하면 된다.


메인 브랜치(master, develop)

git-flow 전략에서 핵심이 되는 브랜치는 master, develop 브랜치이다.

master 브랜치

배포 가능한 상태만을 관리하는 브랜치로 안정적인 버전의 소스들만 관리되는 브랜치이다. master 브랜치의 HEAD는 최신 배포판의 소스코드 버전이 들어있다. master 브랜치는 지난 배포판의 소스코드를 따라가기 위해 태그(tag)들이 추가되어 있다. 이 태그를 확인해서 각 릴리즈 버전의 소스코드를 빠르게 확인한다.

정리해서, master 브랜치는 운영서버에 배포해야 되는 소스코드가 관리되어야 한다(안정성이 충분히 검증된 소스코드).

develop 브랜치

develop 브랜치는 다음에 배포할 것을 개발하는 브랜치이다. develop 브랜치는 통합 브랜치의 역할을 한다. 평소 개발자들은 이 브랜치를 기반으로 개발을 진행해야한다. 개발자들은 develop 브랜치에서 feature 브랜치를 생성하고, 소스코드 수정 및 기능 개발이 완료되면 develop 브랜치로 풀 리퀘스트 요청을 하게 된다.


feature 브랜치

  • 생성되어지는 브랜치 : develop
  • merge 해야되는 브랜치 : develop

feature 브랜치 또는 topic 브랜치라 부른다.

단위 기능을 개발하는 브랜치로 develop 브랜치의 HEAD에서 생성된다. 새로운 기능 개발을 하거나 버그 수정을 위한 코드 수정이 이뤄지는 브랜치로 이해하면 된다. 이 브랜치에서는 개발자 혼자 작업을 할 수 있도 있고, 특정 기능 개발을 위한 여러명의 개발자들이 공동으로 작업할 수도 있다.

feature 브랜치에서 작업이 완료되면 풀 리퀘스트를 요청하여 develop 브랜치에 병합(merge)하게 된다.

여기서 주의해야할 점은 feature 브랜치를 생성한 목적이 완료될 때까지 유지해야하고 다 완성되면 develop 브랜치에 병합해야 한다. 그리고 feature 브랜치는 보통 개발자 저장소에만 있는 브랜치이고 리모트 저장소에는 push하지 않는다.


release 브랜치

  • 생성되어지는 브랜치 : develop
  • merge 해야되는 브랜치 : develop, master

git으로 관리되는 소프트웨어는 정기적으로 성능개선, 기능추가, 버그를 수정 및 반영하면서 릴리즈된다. release 브랜치는 릴리즈를 하기 위한 목적으로 생성되는 브랜치이다. release 브랜치는 develop 브랜치에서 생성된다.

간단한 순서는 아래와 같다.

  • develop 브랜치에 이전 버전에 포함되는 기능이 merge 되어있다면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성한다.
  • 배포를 위한 최종적인 버그 수정 등의 개발을 수행한다.
  • 배포 가능한 상태가 되면 master 브랜치로 병합한다. 출시된 master 브랜치에는 버전 태크를 추가한다.
  • release 브랜치에서 기능을 점검하며 발견한 버그 수정 사항은 develop 브랜치에도 적용해야 한다. 따라서 배포 완료 후 develop 브랜치에도 merge를 해야한다.


hotfix 브랜치

  • 생성되어지는 브랜치 : master
  • merge 해야되는 브랜치 : develop, master

hotfix 브랜치는 배포한 버전에서 긴급하게 수정이 필요한 경우 master 브랜치에서 분기하는 브랜치이다. 다음 릴리즈를 기다릴 수 없을 정도로 긴급한 패치가 바로 반영되어야 하는 경우 이 hotfix 브랜치를 사용한다.

정리해서,

  • hotfix 브랜치는 master 브랜치에서 생성된다.
  • hotfix 브랜치에는 긴급한 패치들이 반영된다.
  • 이후 hotfix 브랜치는 master 브랜치에 병합되고 태그를 추가한다.
  • 마찬가지로 develop 브랜치로도 병합되어 긴급 수정 사항이 이후 릴리즈에도 반영되도록 해야한다.


git-flow 설명

  1. 가장 먼저 master 브랜치에서 시작한다.
  2. master 브랜치와 동일하게 develop 브랜치를 생성해준다. 그리고 개발자들은 develop 브랜치에서 개발을 진행한다.
  3. 개발을 진행하다가 1.회원가입, 2.장바구니, 3.오류수정 등의 기능 구현 및 버그 수정이 필요한 경우
    • A 개발자는 develop 브랜치에서 feature 브랜치를 하나 생성해서 1.회원가입 기능을 구현한다.
    • B 개발자는 develop 브랜치에서 feature 브랜치를 하나 생성해서 2.장바구니 기능을 구현한다.
    • C 개발자는 develop 브랜치에서 feature 브랜치를 하나 생성해서 3.오류수정을 구현한다.
  4. 완료성된 feature 브랜치들은 develop 브랜치에 풀 리퀘스트 요청을 하고 검토가 완료되어 이상이 없으면 merge한다.
  5. 모든 기능이 완료되면 develop 브랜치에서 release 브랜치를 생성한다.. 그리고 QA(품질검사)를 진행하다가 보완점을 보완하고 버그를 수정한다.
  6. 모든 것이 완료되면 release 브랜치를 master 브랜치와 develop 브랜치로 merge한다. master 브랜치에서 버전추가를 위해 태그를 생성하고 배포한다.
  7. 배포를 완료했는데 미처 발견하지 못한 버그가 있는 경우 hotfix 브랜치를 master 브랜치로부터 생성하여 긴급 수정 후 태그를 생성하고 바로 수정 배포를 진행한다.