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 후 삭제

-> GITHUB action으로 브랜치 자동 삭제 안 되나ㅏ?? delete merged branch 이런거 있을거같은데..

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

Issue

라벨링

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

템플릿

feature

이슈 이름

이슈가 다루는 문제

학습 내용

Refs.

bug

# 이슈 이름

## 버그 내용

스크린샷 같은거 첨부

## 버그 해결 과정

PR

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

PR 단위

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

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

• 곧바로 PR 요청
• 실무에서 어떤지 멘토님에게 질문
• CI 테스트 문제도 멘토님에게 질문
• 처음에는 코드 대격변 일어나면서 테스트 코드도 막 바뀌지 않나?

라벨링

issue와 동일

템플릿