Git Commit Message Convention

Code Convention

Class Naming Convention

개발 규칙

브랜치 전략: main/dev/feat/*

• main을 두고, dev에서 pr 멘토님한테 주 1회 리뷰
• 팀원은 feat에서 작업 후 dev에 pr
• 이슈 기반 개발, 브랜치 생성
• 이슈, PR: [대문자/소문자] 내용 → [FEAT/member] 회원 로그인 기능 개발
• 브런치 : <type>/<scope>/#3 -> feat/member/#3
• 브런치는 merge 후 삭제 (pr후)

커밋 컨벤션: <type>(<scope>): <subject> → “feat(bid): ~~~~~~ 구현”

• scope는 domain으로 쪼갠다

• 커밋 단위는 자율적으로 하되, 복잡한 수정은 최대한 확인이 편하게 자르기

  Type	Description
  feat	새로운 기능 추가
  fix	버그 수정
  docs	문서 수정 (README.md 등)
  style	코드 포맷팅, 세미콜론 누락, 공백 등 (기능 변경 없음)
  refactor	코드 리팩토링 (기능 변경 없음)
  test	테스트 코드 추가 또는 수정
  chore	빌드, 패키지 매니저 설정 등 유지보수 작업

PR 규칙:

• PR 탬플릿
  • 탬플릿 (feat/bug)
  • 복잡한 기능에서는 구현 스크린샷을 첨부
  • 특별한 기능을 추가할 때는 왜 이런 기능을, 이런 방식으로 구현했는지 설명을 자세히 적기
  • 코드에 변경사항이 있으면 pr 탬플릿에 작성 (ex. API 주소 추가/변경, 이벤트 추가/변경)
• 리뷰는 필수 인원 외에도 하고 싶은 분야에 편하게 작성
• 리뷰 2명 이상 필수 (pair programming)