[Git]Git 브랜치 관리 전략

in Study on Git

프로젝트 Git 브랜치 관리 전략

브랜치 관리 전략

  • 왜 필요한가?
    • 대부분의 프로젝트는 혼자가 아닌 디자이너, 퍼블리셔, 개발자 등의 많은 구성원들로 이루어진다. 이로 인해 프로젝트의 형상 관리가 어려워짐. 형상 관리의 복잡성을 줄이기 위해 적절한 브랜치 관리 전략 적용이 중요함.

브랜치 전략 종류

Git-flow

  • Vincent Driessen에 의해 제안된 브랜치 전략
  • 기본 브랜치 5가지
    • feature>develop>release>hotfix>master
  • 머지 순서는 앞에서 뒤로 진행

gitflow.png

구성

구성

  1. master : 실제 운영기로 출시된 브랜치 (필수 브랜치)
  2. develop : 개발기 소스 브랜치(다음 출시 버전) (필수 브랜치)
  3. feature : 기능 개발 시 사용하는 브랜치
  4. release : 출시 준비 버전 관리용 브랜치
  5. hotfix : 현재 운영중인 버전에서 발생한 버그 수정을 위한 브랜치
  • master와 develop 브랜치는 필수로 존재해야 한다.
  • 머지 된 feature, release, hotfix 브랜치는 삭제

feature 브랜치

feature.png

  • May branch off from
    • develop 브랜치
  • Must merge back into
    • develop 브랜치
  • 브랜치 명명 규칙
    • master, develop, release-*, hotfix-* 제외하곤 상관 없음

새로운 기능을 추가하는 브랜치
feature 브랜치는 origin에 반영하지 않고, 개발자의 repo에만 존재

merge 할 때, –no-ff 옵션을 이용해 브랜치에서 머지가 됐음을 git 이력에 남김.

  1. feature 브랜치 생성
     $ git checkout -b feature/user-login develop
  2. develop 브랜치에 머지
     $ git checkout develop
 $ git merge --no-ff feature/user-login
 $ git branch -d feature/user-login
 $ git push origin develp
    • --no-ff : squash 머지와 같이 feature 브랜치의 커밋 히스토리와 상관없이 하나의 커밋으로 머지하는 옵션

release 브랜치

  • May branch off from
    • develop 브랜치
  • Must merge back into
    • develop, master
  • 브랜치 명명 규칙
    • release-*

릴리즈를 위한 브랜치.
버그 픽스에 대한 부분만 커밋, 릴리즈 준비 완료 시 master로 머지
master 머지 후 tag 명령어 통해 릴리즈 버전에 대해 명시, -s 또는 -u <key> 옵션을 이용해 머지한 사람의 정보를 남김. 이 후 develop 브랜치로 머지해, release 브랜치에서 수정된 내용이 develop 브랜치에 반영

hotfix 브랜치

  • May branch off from
    • master
  • Must merge back into
    • develop, master
  • 브랜치 명명 규칙
    • hofix-*

master에서 발견된 버그 수정사항을 위한 브랜치. 버그 수정 후 develop, master 브랜치에 반영. 반영 후 master에 tag를 추가.

만약 release 브랜치 존재 시 release브랜치에 hotfix 브랜치를 머지해 릴리즈 될 때 반영되도록 함.

[References]