커밋 및 PR 컨벤션
PR 제목과 초기 본문을 스쿼시 병합(squash-and-merge) 시 적용될 정확한 커밋 메시지로 취급하세요.
커밋 메시지
- 저장소 안내 사항을 먼저 읽으세요. 스코프는 저장소 로컬
commit-scope스킬로 도출하세요. 사용할 수 없으면 명시적인 저장소 규칙을 따르거나 스코프를 생략하세요(임의로 만들지 마세요). - Conventional Commits를 따르세요:
<type>[optional scope][!]: <description>. - 50자를 목표로 하고 결과적인 동작을 설명하세요. 저장소에서 요구하는 스코프를 달성하기 위해 그 목표를 포기하지 마세요. 요구 스코프로 인해 50자 달성이 불가능하면 나머지 설명을 가능한 한 간결하게 유지하세요.
- 제목, 본문, 푸터는 빈 줄로 구분하세요.
- 단일 커밋의 경우 본문 줄을 72자로 감싸세요. 변경이 필요한 이유, 해결 방법, 그리고 중요한 부작용을 설명하세요.
- 기존 티켓 키나 링크는 제목이 아닌 푸터에 넣으세요:
Issue: PROJECT-123. 이슈가 존재할 때는 저장소별 푸터 형식을 따르세요. 이슈가 없으면Issue: N/A같은 것을 만들지 말고 푸터를 생략하세요. - 적용 가능한 Conventional Commits 푸터와 협력자를 위한
Co-authored-by: Name <email>트레일러를 추가하세요. - 타입은 변경이 결함을 수정하는지 여부가 아니라 영향을 받는 표면에 따라 선택하세요.
- CI, 워크플로우, 자동화 변경(해당 자동화에 대한 수정 포함)에는
ci를 사용하세요. - 제품 또는 런타임 버그 및 외부에서 사용하는 공개 API 경계에 대한 비기능 변경에는
fix를 사용하세요. - 기능에는
feat, 빌드 또는 종속성에는build, 비제품 도구나 설정에는chore, 문서 전용에는docs, 의미론적이지 않은 편집에는style, 내부 재구성에는refactor, 테스트에는test, 성능에는perf를 사용하세요. - 호환성을 깨는 변경은 정확한 타입을 바꾸지 않고
!나BREAKING CHANGE푸터로 표시하세요. - 스쿼시되지 않은 모든 개발 커밋은 일관성 있고 관례를 따라야 합니다.
fix(storage): preserve collated indexes
Normalize server-expanded collations before comparing index definitions.
Issue: PROJECT-123
풀 리퀘스트
- 제목을 의도된 스쿼시 커밋 제목 그대로 설정하세요.
- 초기 본문을 의도된 스쿼시 커밋 본문과 푸터 그대로 설정하세요. PR 전용 서문, 체크리스트, 구현 일지는 제외하세요.
- PR 본문을 수동으로 줄 바꿈하지 마세요. GitHub가 표시 줄 바꿈을 처리합니다.
- 영구적인 히스토리를 간결하게 유지하세요: 동기, 주요 동작, 부작용을 기록하세요.
- 실험, 대안, 광범위한 검증, 구현 연대기는 후속 댓글에 넣으세요.
- 변경된 라인을 최소한 프로덕션 코드, 테스트, 기타 파일로 나누어 후속 댓글을 게시하세요. 리뷰어가 코드를 읽기 전에 변경의 비중이 어디에 있는지 확인할 수 있도록 합니다. 라인 수 계산 및 표시 방법은 자유이며, diff가 실질적으로 변경되면 댓글을 새로 고치세요.
- 구현이 발전함에 따라 제목과 초기 본문을 업데이트하세요.
- 열기, 업데이트, 또는 병합 전에
제목 + 빈 줄 + 본문을 하나의 커밋 메시지로 읽고 불일치를 수정하세요.