git flow 운영 정책

서버

• dev : 개발 단계 확인
• stage : QA 검수등의 사용자 테스트
• prod : 운영

 

브랜치

• feature : 담당자 기능 브랜치
• develop : 개발 브랜치
• stage : QA 검수등 테스트 브랜치
• release : 배포 브랜치
  • 일반적인 gitflow 에서는 develop 브랜치가 안정화 되었을때 생성하나, 배포시 브랜치 머지용도로 사용
• master : 운영 브랜치

 

상품 git Flow

[1안]

 

• 기본 프로세스

1. feature → 개발 → PR → develop , release 머지
   1. develop 머지 후 개발자 테스트 수행 중 변경사항 발생 시 위 프로세스(1번)와 동일 수행
2. release → stage, develop 머지
   1. 만약, 개발자가 develop 머지 없이 release에만 머지를 수행할 경우를 대비하여 hook 설정
      1. hook 내용
         1. 로컬에서 release upstream 반영 시 develop에 커밋해쉬정보가 존재하는지 검증합니다.
         2. 위치 : 프로젝트/.git/hooks

 

[2안]

 

1. release를 develop과 stage 에 반영
2. 릴리즈에 없는 내용이 develop이나 stage 에 반영 할 수 없음
   1. feature를 release를 거치지 않고 올리거나, develop, stage 에서 직접 수정후 push 불가
3. develop 을 stage로 반영 할 수 없음
4. v2에 개발된 소스가 배포일자 변경등으로 v1에 포함되어야 하는 경우
   1. v2 전체가 v1으로 포함되어도 되는경우
      1. v2에 v1을 pull 받아 싱크 맞추고 머지
   2. v2 일부가 v1으로 포함되어야 하는 경우
      1. feature에 pull 받아 싱크 맞추고 release v1에 머지

→ 해당 머지과정에서 컨플릭트가 발생할 수 있음(base 브랜치가 다르므로), 발생 된 컨플릭트는 담당자가 해결 후 머지

1. v1에 올린 내용을 수정해야 할 경우 (스테이지 검수과정에서 변경 필요 시)
   1. 해당 release 기준으로 피처를 재생성 및 기존 feature에 해당 release를 pull 받아서, 싱크 맞추고 변경 개발 수행

 

지라 티켓 관련

• 소스 변경이 필요한 작업은 티켓을 생성
• QA 할 내용은 지라 release 에 티켓 추가
• hotfix의 경우 선배포 후 티켓추가 가능

 

브랜치 생성 및 수행 기준

• feature는 develop 기준으로 생성 (PR 수행)
• stage는 release 머지
  • 스테이지 = master 싱크로 배포할 내용만 머지함.
  • 스테이지에는 release 한개의 브랜치만 머지함.
    • ex) 11월 7일 배포건 → release/v231107 → stage
    • ex) 11월 21일 배포건 → release/v231121 → stage
• release는 stage 기준으로 생성
  • 브랜치명 : release 티켓 명 (ex . v231026)
  • 생성시점 : 배포일자 확정 즉시
  • 머지 : feature → release
  • release → stage 시 release → develop 동시 수행 필요
• hotfix 는 master 기준으로 생성
  • 케이스 긴급하게 수정후 바로 머지해야 할 경우
    • develop, master 머지
      • cf) gitFlow 사용 시 develop, master 동시 머지 됨.
  • 케이스 당장 배포하지 않아도 되는 경우
    • PR 수행 후 develop, master 머지 ( PR 시 머지대상 브랜치는 master)

 

GitFlow 설명

feature

• 설명
  • start feature : develop 기준으로 생성
  • publish feature : upstream 반영
  • finish feature : develop 머지
• 사용 예
  • start feature → 개발 → publish feature → PR(비트버켓) → 머지

release

• 설명
  • start release : develop 기준으로 생성
  • publish release : push(upStream 반영)
  • finish release : develop , master 머지
• 사용 예
  • master 브랜치 기준 release/{릴리즈티켓명} 생성 후 push(upStream 반영)
  • release/{릴리즈티켓명} 에 배포 내용 머지
  • finish release : develop , master 머지 → 각 브랜치(develop , master) push → 배포

hotfix

• 설명
  • start hotfix : master 기준으로 생성
  • publish hotfix : push(upStream 반영)
  • finish hotfix : develop , master 머지
• 사용 예
  • start hotfix → publish hotfix → PR → finish hotfix → 각 브랜치(develop , master) push → 배포