PR & Branch Strategy

우리 브랜치 전략은 GitHub Flow를 기반으로, develop을 통합 브랜치로 사용하는 방식입니다.

우리 레포는 develop 브랜치에서 기능을 통합하고, 배포는 main에서 진행합니다. 기능 개발 및 리팩토링 등 개별 작업은 작업 브랜치를 생성해 PR로 develop에 머지하는 흐름을 기본으로 합니다.

---

Branch Rules

Branch	용도	규칙
develop	개발용(통합 브랜치)	모든 작업 브랜치는 develop으로 PR 생성 후 머지
main	배포용(릴리즈 브랜치)	배포 시점에만 develop → main으로 머지
feat/#<issue>/<name>	기능 작업용	ex) feat/#1/card
fix/#<issue>/<name>	버그 수정용	ex) fix/#12/splash-redirect
refactor/#<issue>/<name>	리팩토링 작업용	ex) refactor/#2/my-page
style/#<issue>/<name>	스타일/포맷 작업용	ex) style/#31/import-order
test/#<issue>/<name>	테스트 작업용	ex) test/#18/bar-graph-utils
chore/#<issue>/<name>	설정/잡무 작업용	ex) chore/#7/commitlint

작업 브랜치는 이슈 기반으로 생성하며, 브랜치 이름에 반드시 #이슈번호를 포함합니다. 슬래시는 구분자로 사용하고, <name>은 케밥 케이스를 권장합니다(예: my-page, bar-graph-motion, splash-redirect).

---

PR Rules

PR은 작업 브랜치에서 develop을 대상으로 생성합니다. PR 제목은 커밋 컨벤션과 동일하게 type: subject 형식을 권장하며, 변경 목적이 한 줄로 바로 이해되도록 작성합니다.

머지 조건은 최소 1명 승인(Approve) 필수이며, 승인 없이 머지하지 않습니다. 리뷰 반영이 필요한 코멘트가 있으면 우선 반영하고, 논의가 필요한 경우 PR 내 스레드로 합의한 뒤 진행합니다.

---

Merge Strategy

기본 머지는 develop에만 수행하며, main에는 배포 시점에만 머지합니다. 따라서 main은 항상 배포 가능한 상태를 유지하고, 기능/리팩토링 작업은 모두 develop에서 검증 후 릴리즈됩니다.