kch-commit

# KCH 커밋 규칙 ## 메시지 - 제목은 사용자 변화나 작업 목적을 한국어 한 문장으로 쓴다. `feat:`, `fix:` 같은 영문 접두어는 필수가 아니다. - 기술·파일 이름 나열보다 사용자 행동과 결과를 설명한다. ‘수정’, ‘작업 완료’, ‘기능 개선’ 같은 모호한 제목을 피한다. - 본문은 이유·중요한 제한·데이터 변경처럼 제목만으로 설명할 수 없는 내용이 있을 때만 덧붙인다. 좋은 예: - `관리자가 장비를 등록하고 보관 위치를 수정할 수 있게 한다` - `같은 자산번호의 장비가 중복 등록되지 않도록 한다` - `팀원이 같은 절차로 개발하고 검토할 수 있도록 안내한다` 피할 예: `feat: implement asset CRUD`, `router.go 및 Assets.tsx 수정`, `버그 수정`. ## 실제 커밋 이슈 1개에 대응하는 PR 안에서 목적별 작업 단위 커밋을 만든다. 한 이슈를 여러 커밋으로 구현할 수 있지만 다른 이슈의 변경을 섞지 않는다. 테스트와 해당 구현은 함께 검토·되돌릴 수 있게 묶고 파일별로 기계적으로 나누지 않는다. 1. 메시지 작성만 요청받았다면 실제 커밋은 하지 않는다. 실제 커밋이 승인된 범위인지 확인한다. 2. 브랜치·상태·diff를 확인하고 한 가지 설명 가능한 목적 단위로 묶는다. 타인의 변경·비밀키·직원 정보·DB·불필요한 생성물을 제외한다. 3. 대상 파일을 명시해 stage하고 staged diff를 확인한다. 실제 실행한 검증 결과만 기록하고 새 변경 없이 이미 통과한 검사를 반복하지 않는다. 4. 커밋 후 식별자와 남은 변경을 확인한다. 커밋 요청을 push·PR·병합 허가로 확대하지 않는다.