깃 브랜치 전략

브랜치 구조

• 개발/프로덕션 서버를 따로 만들기
  • 프로덕션 서버는 deploy 브랜치에 Jenkins 연결
  • 개발 서버는 develop 브랜치에 Jenkins 연결
• Release
  • develop에서 release 브랜치 만들어서 deploy 브랜치에 머지

master (default)
│
├─ deploy (프로덕션 브랜치)
│
├─ develop/FE 
│  └─ feature/FE/{story}
│
├─ develop/BE
│  └─ feature/BE/{story}
│
├─ docs
...

DEV 주의사항

• FE와 BE를 따로 디렉토리에 감싸 관리해야한다

DOCS 관리

• docs 디렉토리에 감싸 관리해야한다

develop, feature 브랜치 전략

• feature 브랜치 이름은 기능이 나타나도록 작성
  • feature 브랜치는 스토리 단위로 생성
  • feature/BE/login
  • feature 브랜치에 커밋은 태스크 단위

gitGraph
    commit
    branch develop/FE
    commit
    branch feature/FE/story
    commit id: "Task 1"
    commit id: "Task 2"
    checkout develop/FE
    merge feature/FE/story
    checkout main
    branch develop/BE
    commit
    checkout develop/BE
    branch feature/BE/story
    commit id: "Task3"
    checkout develop/BE
    merge feature/BE/story

Loading

PR 전략

• PR은 피쳐 기능 단위로
• PR 날리는 시점 (2가지)
  • feature 브랜치에서 태스크 모두 완료 (하루의 언제든 가능)
  • 23시까지 완료한 부분 (태스크 모두 완료 못한 경우)
• PR 날리면 파트장의 확인 후 머지
  • FE(3인) - 매일 FE 파트장을 번갈아 가면서 담당하며, FE의 PR을 확인 후 merge / FE 파트장은 전일 파트장을 담당한 인원이 PR을 확인 후 merge
  • BE(2인) - BE 파트장(서정)
  • 상세한 코드 리뷰는 PR 시점이 아닌 23시에 일괄 진행
  • 머지 완료 후 파트 구성원들은 rebase 후 개발 진행
• PR이 develop에 머지되면 브랜치 삭제