Branch 전략

• main
  • protected
• dev
• feature
  • feature/{fe|be|cicd}/{issue number}-{feature name}
  • ex) feature/fe/12-account
  • 이슈 넘버는 유저 피쳐 이슈로부터 파생된 개발 이슈 번호를 기재합니다.
  • 유저 피쳐에는 파생된 이슈를 댓글이나 이슈 디스크립션에 기재해서 추적 가능하게 합니다.
• fix
  • fix/{issue-number}-{feature name}

1. 월요일에 큰단위 피처리스트에서 피처를 가지고 프론트 백에서 각각 이슈 생성
   1. 프론트엔드
      1. 컴포넌트 단위
   2. 백엔드
      1. 개발 단위
2. feature, fix 단위로 브랜칭하여 개발
3. feat/fix 브랜치 리뷰 후 dev에 merge
   1. 급한 PR의 경우 slack 연락 후 확인하고 바로 merge
4. 매일 오전 서로의 PR 확인 후 Merge하는 과정 PR 이후 24시간 내로 리뷰해주세요. 문제가 없는 경우 마지막으로 리뷰한 사람이 Merge합니다.
5. feature issue는 동작 확인 후 Done으로 이동합니다.
6. development issue는 merge 후 Done으로 이동합니다.
7. 목요일 배포 전 dev -> main

브랜치 과다 어떻게?

PR 후 삭제

https://github.com/marketplace/actions/delete-merged-branch

Issue

라벨링

• bug
• feature