8.5 KiB
Commit Message Convention / 커밋 메시지 규칙
이 문서는 git-rewrite-commits(node 기반 도구)가 참고하는 커밋 메시지 형식 규칙을 정의합니다.
This document defines the commit message format used by the node-based tool git-rewrite-commits.
파일 위치: COMMIT_MESSAGE.md
1. 기본 형식 (Basic Format)
1.1 형식 (Format)
- 형식 / Format
[type] short description [BREAK] - 규칙 / Rules:
type은 반드시 대괄호[]안에 들어가야 합니다.
typeMUST be enclosed in square brackets[].short description에는 작업 내용을 간단하고 명확하게 한 줄로 작성합니다.
short descriptionMUST briefly and clearly describe what the commit does.- 중대한 변경(BREAKING CHANGE) 가 있을 경우, 메시지 끝에
[BREAK]를 추가합니다.
If there is a breaking change, append[BREAK]at the end.
1.2 예시 (Examples)
-
일반 커밋 / Normal commits
[feat] add dtls handshake client[fix] wrong dtls listen port[docs] update README ko/en
-
브레이킹 체인지 / Breaking changes
[config] rename env variables for server port [BREAK][feat] change dtls handshake message format [BREAK][refactor] remove legacy proxy api [BREAK]
2. 타입 규칙 (Type Rules)
아래 타입들은 우선순위가 높은 것부터 나열되어 있습니다.
Commit types are listed in priority order (highest first).
2.1 High-priority impact types (상위 우선순위 타입)
-
[breakfix]– 긴급/심각한 문제 수정 (긴급 영향)- 사용 시점 / When to use:
- 프로덕션 장애나 보안 취약점 등, 즉시 수정이 필요한 심각한 문제를 해결할 때.
For critical production issues or security fixes requiring immediate attention.
- 프로덕션 장애나 보안 취약점 등, 즉시 수정이 필요한 심각한 문제를 해결할 때.
- 예 / Examples:
[breakfix] fix dtls denial-of-service bug [BREAK][breakfix] hotfix wrong admin auth check
- 사용 시점 / When to use:
-
[feat]– 새 기능 추가 (Feature)- 새로운 기능, API, 큰 동작 변화 추가.
New features, APIs, or significant behavioral changes. - 예 / Examples:
[feat] add admin domain register api[feat] support multiple dtls clients per domain [BREAK]
- 새로운 기능, API, 큰 동작 변화 추가.
-
[config]– 설정/환경/배포 관련 변경 (Config / Env / Infra)- 환경 변수, 설정 파일, 인프라 관련 변경.
Configuration, environment variables, infra-related changes. - 환경변수 이름/의미가 바뀌면 반드시
[BREAK]추가.
If env names/semantics change, ALWAYS append[BREAK]. - 예 / Examples:
[config] add HOP_SERVER_DEBUG env[config] rename HOP_CLIENT_SERVER_ADDR to HOP_CLIENT_DTLS_ADDR [BREAK]
- 환경 변수, 설정 파일, 인프라 관련 변경.
-
[db]– 데이터베이스/스키마 변경 (Database / Schema)- ent 스키마 변경, 마이그레이션, 인덱스 변경 등.
ent schema changes, migrations, indexes, etc. - 호환성이 깨지는 스키마 변경이면
[BREAK].
Use[BREAK]for incompatible schema changes. - 예 / Examples:
[db] add domain uuid primary key[db] drop legacy domain table [BREAK]
- ent 스키마 변경, 마이그레이션, 인덱스 변경 등.
-
[refactor]– 리팩터링 (Refactor)- 기능 변경 없이 구조/설계 개선.
Structural/design improvements without changing behavior. - 예 / Examples:
[refactor] extract dtls handshake into internal/dtls[refactor] simplify admin handler routing
- 기능 변경 없이 구조/설계 개선.
2.2 Normal change types (일반 변경 타입)
-
[fix]– 버그 수정 (Bug Fix, non-critical)- 치명적이지 않은 일반 버그 수정.
Non-critical bug fixes. - 예 / Examples:
[fix] handle empty domain in admin register[fix] correct log field name for client_id
- 치명적이지 않은 일반 버그 수정.
-
[perf]– 성능 개선 (Performance)- 성능 최적화, 메모리/지연 시간 감소.
Performance improvements (latency, memory, throughput). - 예 / Examples:
[perf] reuse dtls buffers[perf] reduce log allocations
- 성능 최적화, 메모리/지연 시간 감소.
-
[docs]– 문서 (Documentation)- README, ARCHITECTURE, 주석 등 문서 변경.
Documentation changes (README, ARCHITECTURE, comments). - 예 / Examples:
[docs] add ko/en README[docs] update architecture handshake flow
- README, ARCHITECTURE, 주석 등 문서 변경.
-
[test]– 테스트 (Tests)- 유닛/통합 테스트 추가/수정.
Adding or updating tests. - 예 / Examples:
[test] add dtls handshake unit tests[test] fix flaky proxy integration test
- 유닛/통합 테스트 추가/수정.
-
[build]– 빌드/도구 (Build / Tooling)- Makefile, Dockerfile, CI 스크립트 등 빌드 파이프라인 관련.
Build pipeline changes (Makefile, Dockerfile, CI). - 예 / Examples:
[build] add dockerfile for server[build] update make targets for client
- Makefile, Dockerfile, CI 스크립트 등 빌드 파이프라인 관련.
-
[chore]– 관리용 잡일 (Chore / Maintenance)- 코드 포맷팅, 의존성 업그레이드, 단순 정리 등.
Maintenance tasks: formatting, dependency bumps, trivial cleanups. - 예 / Examples:
[chore] bump pion dtls to v3.x[chore] clean up unused imports
- 코드 포맷팅, 의존성 업그레이드, 단순 정리 등.
2.3 Optional / Special types (선택적 / 특수 타입)
-
[debug]– 디버깅 / 로깅 임시 커밋 (Temporary Debug)- 로그 추가, 임시 디버그 코드, 포트/주소를 바꿔가며 실험하는 커밋.
Temporary debug logs or experimental changes. - 브레이킹 변경(예: 포트/환경변수 변경)이 포함되면
[BREAK]추가.
Append[BREAK]if it includes breaking changes (e.g., port/env change). - 예 / Examples:
[debug] log dtls handshake flow[debug] change client port for local test [BREAK]
- 로그 추가, 임시 디버그 코드, 포트/주소를 바꿔가며 실험하는 커밋.
-
[revert]– 이전 커밋 되돌리기 (Revert)- 이전 커밋을 되돌리는 경우.
Reverts a previous commit. - 예 / Examples:
[revert] revert dtls handshake change
- 이전 커밋을 되돌리는 경우.
-
[wip]– 작업 진행 중 (Work in Progress)- 미완료 상태의 임시 커밋 (가능하면 main/master에는 남기지 않기).
Work-in-progress commits (avoid keeping them on main/master). - 예 / Examples:
[wip] refactor proxy routing table
- 미완료 상태의 임시 커밋 (가능하면 main/master에는 남기지 않기).
3. 브레이킹 변경 표시 (Marking Breaking Changes)
중대한 변경사항(브레이킹 체인지)이 있을 때는 항상 메시지 끝에 [BREAK] 를 붙입니다.
Whenever there is a breaking change, always append [BREAK] at the end of the message.
브레이킹 변경의 예 / Examples of breaking changes:
-
환경 변수 이름/의미 변경 (Env var name/semantics change)
- 예:
HOP_SERVER_DTLS_LISTEN→HOP_SERVER_DTLS_ADDR - Example:
HOP_SERVER_DTLS_LISTEN→HOP_SERVER_DTLS_ADDR - 커밋 예시 / Commit example:
[config] rename dtls listen env to HOP_SERVER_DTLS_ADDR [BREAK]
- 예:
-
DB 스키마 비호환 변경 (Incompatible DB schema change)
- 컬럼 삭제, 타입 변경, 테이블 드롭 등.
Dropping columns, changing types, dropping tables, etc. - 예 / Example:
[db] drop legacy domain table [BREAK]
- 컬럼 삭제, 타입 변경, 테이블 드롭 등.
-
외부 API / 프로토콜 계약 변경 (External API / protocol contract changes)
- 핸드셰이크 메시지 포맷 변경, HTTP 경로/쿼리 변화 등.
Changing handshake message format, HTTP paths, query params, etc. - 예 / Example:
[feat] change dtls handshake json fields [BREAK]
- 핸드셰이크 메시지 포맷 변경, HTTP 경로/쿼리 변화 등.
-
포트/리스너 동작 변경 (Port / listener behavior change)
- 기본 포트 변경, TLS/DTLS 포트 매핑 변경 등.
Changing default ports, TLS/DTLS mapping, etc. - 예 / Example:
[config] change default dtls port to 8443 [BREAK]
- 기본 포트 변경, TLS/DTLS 포트 매핑 변경 등.
4. 요약 (Summary)
- 커밋 메시지는 항상 다음 형식을 사용합니다:
Always use this format for commit messages:[type] short description [BREAK] type은 위에서 정의한 타입 중 하나를 사용합니다.
typeMUST be one of the defined types above.- 환경 변수, 스키마, 프로토콜 등 호환성을 깨는 변경이 있다면
[...] [BREAK]를 반드시 추가합니다.
If there are any compatibility-breaking changes (env, schema, protocol, etc.), ALWAYS append[BREAK].
이 규칙을 따르면, git-rewrite-commits 및 기타 도구들이 커밋 히스토리를 안정적으로 분석하고 재작성할 수 있습니다.
Following these rules allows git-rewrite-commits and other tools to reliably analyze and rewrite commit history.