git-flow(git 브랜치 모델)

Tags:

git flow

2010년에 빈센트 드리센(Vincent Driessen)이 쓴 ‘A Successful Git Branching Model(성공적인 Git 브랜치 모델)’ 이라는 블로그 기사에서 제안된 브랜치 전략

git flow

각 브렌치의 활용에 대한 설명은 아래와 같다.

  1. 메인브랜치 : 중앙 레파지토리와 그것을 클론한 각 개발자의 레파지토리에 의존하는 중심 브랜치
    • master
      • 배포를 위한 브랜치, 배포를 할 때마다 태그를 부여한다.
    • develop
      • 개발용 브랜치, 배포전의 최신 버전
  2. 서포트 브랜치 : 원칙상 각 개발 멤버의 레파지토리에만 의존하고 역할이 끝난 시점에 사라지는 주기가 짧은 브랜치
    • feature
      • develop로부터 파생되고 특정 기능 개발을 위해 작성되는 브랜치, 기능개발이 끝나면 develop에 머지되고 사라진다.
    • release
      • develop로부터 파생되며, 배포 준비를 위한 브랜치, 배포 준비 작업 중에 불필요한 feature가 끼어들지 못하도록 하기 위해 만들어진다.
      • 배포가 끝나면 master와 develop에 머지된 후 사라진다.
    • hotfix
      • 주로 배포가 끝난 제품에 장애가 발생한 경우 긴급하게 만들어지는 브랜치, master로 부터 직접 파생되며 버그를 수정한 후 master에 머지되고 태그가 부여된다.
      • 또한, 버그 수정이 나중에 누락되지 않도록 develop에도 머지한다. 만약 배포 작업중에 release가 존재하고 있는 경우에도 머지한다.

더욱 심플하게 one 브랜치로 가져가려면

  1. Master는 항상 배포 가능하다.
  2. 새롭게 무언가 진행 할때는 master에서 직접 브랜치를 만든다.
  3. 작성한 브랜치는 로컬 장비에 커밋하고 원격 레파지토리에도 같은 이름의 브랜치로 정기적으로 Push한다.
  4. 개발이 완료되면 Master에 Pull Request한다.
  5. Pull Request가 검증되면 Master에 머지하고 바로 환경에 배포한다.
  • Pull Request가 검증된 후 바로 머지해서 배포하므로, Pull Request를 보내기 전 테스트가 완료되어야 한다(수동/자동)
    • master는 항상 배포가 가능하도록 되어있어야 한다, 머지가 된다는 것은 바로 배포가 가능하다는 의미이다.

Git branch network

branch branch

주요 Branch

브랜치명 분류 설명
work 메인 브랜치 모든 작업 브랜치는 work branch 합쳐지고, 분기합니다.
해당 브랜치는 삭제될수 없는 프로젝트의 모든 작업 소스를 담고있는 메인 브랜치 입니다.
develop 배포 브랜치 dev 환경 배포를 위한 branch
test 배포 브랜치 test 환경 배포를 위한 branch
master 배포 브랜치 pre, live 환경 배포를 위한 branch
feature/ 작업 브랜치 신규 개발을 위한 브랜치
bugfix/ 작업 브랜치 오류 수정을 위한 브랜치
hotfix/ 작업 브랜치 긴급 수정을 위한 브랜치
release/ 배포 브랜치 Custom 배포를 위한 브랜치로써, Work 브랜치 위에서 배포가 불가능한 상황일때 사용합니다. (Cherry-pick 을 통한 선택적 배포 진행시)
  • 메인 브랜치 (work)는 PR merge만을 허용하는 정책으로, 작업 브랜치에서 작업한 내용들은 반드시 Pull-Request를 통해 메인 브랜치에 합쳐집니다.
  • 배포 브랜치 (develop, test, master)는 언제든 삭제가 가능하고, 원하는 배포 커밋 시점에서 새로 생성을 할 수 있습니다.
  • 작업 브랜치 (feaultre/, bugfix/, hotfix)는 메인 브랜치에 PR된 후에는 제거대상 브랜치가 됩니다.

Branch 정책

모든 작업 브랜치는 Jira 이슈와 연동이 되어야 합니다.

JIRA 이슈 관리 연동 Process

  1. Jira 이슈 생성
  2. 분기점 만들기 (Jira 이슈태그 자동생성)
    • ex) feature/PROJ-1
  3. 커밋 메시지에 Jira 이슈번호를 붙여 자동 연동
    • ex) feat(PROJ-1): 프로젝트 init
  4. 작업 완료 후 work브랜치에 pull-request
  5. 작업 브랜치 제거

Rebase 정책

Rebase 정책 Rebase 정책

작업 브랜치 → 메인 브랜치 PR시 반드시 rebase work를 통해 work 최상위로 base를 변경하고, 하나의 커밋으로 통합하여 PR을 진행합니다.

(git rebase -i : 커밋 통합 기능)

Rebase를 필수로 진행해야 하는 이유

  • Clean branch network
  • 메인 브랜치에 merge시, 작업자가 직접 conflict를 해결하고 PR을 진행할수 있습니다.
  • 기능당 1-commit을 통해 1 cherry pick → 1 기능이 보장됩니다.
  • 아무리 많은 작업자가 함께 작업을 진행해도, 브랜치 모델이 심플하게 유지되고 새로운 작업자 에게도 러닝커브가 높아지지 않습니다.
  • 그래프가 깔끔하고 단순해져 코드흐름 파악 및 명확한 배포 시점을 정하기 용이합니다.

Pull Request 정책

  • 작업 브랜치 생성
  • 작업 브랜치에서 개발
  • 개발완료후 rebase (git rebase -i) → 해당과정을 통해 충돌 해결 및 하나의 커밋으로 통합
  • 메인 브랜치로 PR
  • 코드 리뷰 (Default reviewer 1명)
  • 작업자가 직접 PR 승인
  • 메인 브랜치에 머지가 완료된 작업브랜치는 제거

커밋 메세지 규칙

git commit message Convention

공통사항

  • subject
    • 필수사항으로 커밋 내용을 간략하게 정리하여 작성한다.
  • body
    • 선택사항으로 부가적인 정보 작성이 필요할 경우 작성한다.
  • footer
    • 선택사항으로 영향도(영향도: PC/MW/APP)
    • 또는 부가적으로 tracking이 필요하거나 연관 된 issue key를 작성한다.

브렌치 분류별

type brach name msg convertion remarks
feature feature/{ISSUE-KEY}* feature(ISSUE-KEY): subject
body
footer		 새로운 기능 추가
bugfix bugfix/{ISSUE-KEY}* bugfix(ISSUE-KEY): subject
body
footer		 QA도중 수정이 발생할 경우
hotfix hotfix/{ISSUE-KEY}* hotfix(ISSUE-KEY): subject
body
footer		 운영중에 장애로 수정이 발생할 경우
release release/{ISSUE-KEY}
또는
release/yyyymmdd/{ISSUE-KEY}		 release: subject
issue-key-list
body
footer		 배포 시점을 표기할 경우
docs docs/* docs: subject
body		 문서류의 내용을 수정할 경우
e.g. javadoc, README.md
refactor refactor/* refactor: subject
body		 코드 리팩토링을 할 경우
test test/* test: subject
body		 테스트 코드, 리펙토링 테스트 코드 추가 할 경우
config config/* config: subject
body		 설정파일 수정할 경우
e.g. *.config, *.properties, *.yml



최종 수정 : 2022-08-25