✨Project Convention✨

---

✉️ Commit Convention

커밋 메시지는 Udacity 스타일을 사용하며, 다음과 같은 구조로 작성

type: Subject (제목)

body (본문) (긴 설명이 필요한 경우에 작성)

footer  (꼬리말) (issue tracker ID를 명시하고 싶은 경우에 작성)

🛠 type: 커밋의 유형

타입	설명
feat	✨ 새로운 기능 추가
fix	🐛 버그 수정
docs	📝 문서 수정 (README, 주석 등)
style	💄 코드 포맷팅, 세미콜론 누락 등 기능 영향 없는 변경
refactor	♻️ 코드 리팩토링 (기능 변화 없음)
test	✅ 테스트 코드 추가 또는 수정
chore	🔧 빌드 설정, 패키지 매니저 설정 등 기타 작업
perf	⚡ 성능 개선
ci	🔄 CI 관련 설정 및 스크립트 수정
revert	⚙️ 이전 커밋 되돌리기

🖊️ Subject: 제목

• 50자 이내로 간결하게 작성
• 마침표(.) 금지
• 과거 시제 X, 명령어 사용

📝 Body: 본문

• 선택 사항
• 제목에서 설명할 수 없는 추가 정보를 제공
• "무엇을"과 "왜"를 중심으로 상세히 기술
• 한 줄당 72자 이내로 작성
• 필요시 Markdown 사용 가능

---

🌿 Git Flow 브랜치 전략 (with main) 🌿

🌴 기본 브랜치

브랜치	역할
main	최종 배포용 브랜치 (stable)
develop	다음 배포를 위한 통합 개발 브랜치

🌱 작업 브랜치 네이밍 규칙

type/#issue번호  (작업 단위는 기능/수정/리팩토링 등으로 구분)

prefix	설명	예시
feature/	✨ 새로운 기능 개발	feature/#15
fix/	🐛 버그 수정	fix/#42
refactor/	♻️ 코드 리팩토링	refactor/#23
chore/	🔧 설정 변경, 잡일	chore/#25
perf/	⚡ 성능 개선	perf/#94
hotfix/	🚑 급한 수정 (main에서 바로 분기)	hotfix/#102
test/	🧪 테스트 코드 추가/수정	test/#55

🚀 브랜치 흐름 요약

1. main ← 배포
2. develop ← 통합 개발 (PR 대상)
3. develop에서 feature/fix/... 브랜치 분기
4. 기능 완료 후 develop으로 PR & 머지
5. 배포 시 develop → main 머지
6. 급한 수정은 hotfix에서 main → develop 병합

---