Rules.md

🚀 Conventions

이 문서는 채널링 FE 프로젝트의 원활한 협업과 일관성 있는 코드베이스 유지를 위한 규칙을 담고 있습니다. 프로젝트에 참여하는 모든 분은 이 가이드를 숙지하고 따라주시길 바랍니다.

🌳 브랜치 전략 (Branching Strategy)

우리 프로젝트는 Git-flow에 기반한 간단한 브랜치 전략을 사용합니다.

• main: 배포 가능한 프로덕션 코드를 담고 있는 브랜치입니다. 오직 develop 브랜치로부터의 병합(Merge)만 허용됩니다.
• develop: 다음 버전 배포를 위해 개발 중인 코드를 담고 있는 브랜치입니다. 모든 기능 개발은 이 브랜치를 기준으로 합니다.
• [dev/fix/docs]/{기능-이름}: 새로운 기능을 개발하는 브랜치입니다.
  • 생성 위치: develop 브랜치에서 생성합니다.
  • 병합 위치: 기능 개발이 완료되면 develop 브랜치로 Pull Request(PR)를 보냅니다.
  • 브랜치 이름 규칙: 영어 소문자, 숫자, 하이픈(-)을 사용하여 간결하게 작성합니다.
    • 예시: dev/login-page, fix/login-not-working, docs/update-readme
• hotfix/{이슈-이름}: main 브랜치에 발생한 긴급한 버그를 수정하는 브랜치입니다.
  • 생성 위치: main 브랜치에서 생성합니다.
  • 병합 위치: 수정 완료 후 main과 develop 브랜치 모두에 병합합니다.

💬 커밋 메시지 컨벤션 (Commit Message Convention)

우리는 Conventional Commits 양식을 따릅니다. 이는 커밋 히스토리를 명확하게 하고, 버전 관리를 자동화하는 데 도움이 됩니다.

커밋 메시지 구조

<type>: <subject>

• **<type>**과 :(콜론), 그리고 <subject> 사이에는 공백이 하나 있어야 합니다.

1. Type (타입)

커밋의 성격을 나타내는 타입입니다. 첫 글자는 소문자로 작성해야 합니다.

타입	설명
feat	새로운 기능 추가
fix	버그 수정
docs	문서 수정 (README, Rules 등)
style	코드 포맷팅, 세미콜론 추가 등 기능 변경 없는 스타일 수정
refactor	코드 리팩토링 (기능 변화 없이 구조 개선)
test	테스트 코드 추가 및 수정
chore	빌드, 패키지 매니저 설정 등 기타 잡일
ci	CI/CD 구성 파일 및 스크립트 변경
design	CSS 등 사용자 UI 디자인 변경
rename	파일 혹은 폴더명을 수정하는 경우
remove	파일을 삭제하는 작업만 수행한 경우
!BREAKING	API 변경 → 이전 버전 동작 X
!HOTFIX	치명적 버그

2. Subject (제목)

• 50자를 넘지 않도록 간결하게, 핵심 내용을 담아 작성합니다.
• 문장의 끝에 마침표(.)를 찍지 않습니다.

커밋 메시지 예시

• feat: 소셜 로그인 기능 추가
• fix: 모바일 환경에서 헤더 레이아웃 깨짐 수정
• docs: README 파일에 설치 방법 업데이트
• style: 전체 파일에 Prettier 적용
• refactor: useUser 훅 로직 개선

🎫 이슈 컨벤션 (Issue Convention)

이슈는 GitHub Projects 보드에서 생성하고 상태 관리하는 것을 권장합니다.

• 제목: [라벨] 이슈 내용 요약 형식으로 작성합니다. (예: [FIX] 메인 페이지에서 이미지 로딩 안 됨)
• 내용: 재현 방법, 기대 결과, 실제 결과, 스크린샷 등을 포함하여 다른 사람이 문제를 명확히 이해할 수 있도록 상세히 작성합니다.
• 라벨 (Labels): 이슈의 성격에 맞는 라벨(bug, feature, docs 등)을 반드시 추가합니다.

📬 PR(Pull Request) 컨벤션

• 제목: [라벨] 작업 내용 요약 형식으로 작성합니다. (예: [DEV] 로그인 페이지 UI 구현)
• 내용:
  • 관련 이슈: Closed #이슈번호 또는 Fixes #이슈번호를 포함하여 관련 이슈가 자동으로 닫히도록 합니다.
  • 작업 내용: 이 PR에서 어떤 작업을 했는지 목록 형식으로 요약합니다.
  • 스크린샷: UI 변경 사항이 있는 경우, 변경 전후 스크린샷을 반드시 첨부하여 리뷰어가 쉽게 이해할 수 있도록 합니다.
• 리뷰 요청: 최소 1명 이상의 리뷰어를 지정합니다.

✨ 코딩 스타일 (Coding Style)

코드 스타일의 일관성을 유지하기 위해 Prettier와 ESLint를 사용합니다.

• 코드를 커밋하기 전에 반드시 포맷팅을 실행하여 스타일을 통일해주세요.
• 되도록 VSCode 확장 프로그램을 설치하여 파일 저장 시 자동으로 스타일이 적용되도록 설정하는 것을 권장합니다.