gil/fe-common-rules
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
2def6f705dff3c9bd71795a7c3bd4d2c0a8cb529
fe-common-rules/rules/commit-pr.md

2.1 KiB
Raw Blame History

커밋 / PR 규칙

커밋 메시지

Conventional Commits를 따릅니다.

<type>(<scope>): <subject>

<body>

<footer>

type

  • feat: 새로운 기능 추가
  • fix: 버그 수정
  • refactor: 기능 변화 없는 구조 개선
  • style: 코드 포맷/세미콜론 등 스타일 변경
  • docs: 문서 수정
  • test: 테스트 추가/수정
  • chore: 빌드, 설정, 패키지 업데이트 등
  • perf: 성능 개선
  • ci: CI 설정 변경

작성 규칙

  • subject는 50자 이내, 명령형 현재 시제(예: add, fix — added, fixes 아님)
  • subject 끝에 마침표를 찍지 않습니다.
  • body는 "무엇을"보다 "왜"를 설명합니다. 한 줄 72자 이내로 줄바꿈합니다.
  • 한 커밋에는 하나의 논리적 변경만 담습니다.

예시

feat(user): add profile image upload

프로필 이미지 업로드 요구사항에 따라 multipart 업로드 경로를 추가했습니다.
기존 텍스트 필드 업데이트 API는 변경하지 않았습니다.

Refs: #123

Pull Request

제목

커밋 메시지와 동일한 컨벤션을 따릅니다. (<type>(<scope>): <subject>)

본문 템플릿

## 변경 사항
- 무엇이 바뀌었는지 요약

## 배경 / 이유
- 왜 이 변경이 필요했는지

## 테스트
- 어떻게 검증했는지 (수동/자동 테스트 내용)

## 스크린샷 (UI 변경 시)
- Before / After

## 체크리스트
- [ ] 로컬에서 빌드/테스트 통과
- [ ] 린트/포맷 통과
- [ ] 공통 지침(fe-common-rules) 준수
- [ ] 관련 문서 업데이트

리뷰 기준

  • 최소 1명 이상의 승인 필요
  • CI(Lint / Test / Build) 전부 통과 필요
  • 머지 전략은 Squash and merge를 기본으로 합니다.
  • 리뷰어는 변경 범위에 대해 질문이 남지 않도록 배경을 충분히 이해한 뒤 승인합니다.

Draft PR

  • 작업 중간 중간 피드백이 필요한 경우 Draft로 먼저 올리는 것을 권장합니다.
  • Draft 상태에서는 CI 실패가 있어도 괜찮습니다.