Github Rule

Branch 전략

• main
  • protected
• dev
• feature
  • feature/{issue number}-{feature name}
  • ex) feature/12-account
• fix
  • fix/{issue-number}-{feature name}

1. feature, fix 단위로 브랜칭하여 개발
2. feat/fix 브랜치 리뷰 후 dev에 merge
   1. 급한 PR의 경우 slack 연락 후 확인하고 바로 merge
3. 매일 오전 서로의 PR 확인 후 merge하는 과정
4. 목요일 배포 전 dev -> main

브랜치 과다 어떻게?

PR 후 삭제

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

Issue

라벨링

• bug
• feature
• enhancement
• docs
• frontend
• backend

issue 템플릿

feature

# 이슈 이름

## 이슈가 다루는 문제

## 학습한 내용

### Refs. (레퍼런스)

bug

# 이슈 이름

## 버그 내용

스크린샷 같은거 첨부

## 버그 해결 과정

PR

PR 확인한 사람은 리뷰어로 등록

PR 단위

• ISSUE 마다 겪은 문제들 이슈 안에 코멘트로 달기

• PR 종속 문제는 어떻게 해결?

• 곧바로 PR 요청

라벨링

issue와 동일

feature 관리 전략

스프린트 회의 때 유저 피쳐를 개발 단위 이슈로 분할

유저 피쳐를 Issue 컨버트

유저 피쳐에서 여기서 분할된 이슈를 커멘트로 추가

분할된 이슈로 프로젝트 할당하고 관리

분할된 이슈들이 모두 close되면 유저 피쳐도 done으로 이동

브랜치 단위는 유저 피쳐