mirror of
https://github.com/dalbodeule/hop-gate.git
synced 2025-12-07 20:35:44 +09:00
[chore](docs): update commit message guidelines and remove old file
This commit is contained in:
dalbodeule
204
.github/COMMIT_MESSAGE.md
vendored
204
.github/COMMIT_MESSAGE.md
vendored
@@ -1,204 +0,0 @@
|
|||||||
# Commit Message Convention / 커밋 메시지 규칙
|
|
||||||
|
|
||||||
이 문서는 git-rewrite-commits(node 기반 도구)가 참고하는 **커밋 메시지 형식 규칙**을 정의합니다.
|
|
||||||
This document defines the **commit message format** used by the node-based tool git-rewrite-commits.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 1. 기본 형식 (Basic Format)
|
|
||||||
|
|
||||||
### 1.1 형식 (Format)
|
|
||||||
|
|
||||||
- **형식 / Format**
|
|
||||||
```text
|
|
||||||
[type] short description [BREAK]
|
|
||||||
```
|
|
||||||
- 규칙 / Rules:
|
|
||||||
- `type` 은 반드시 대괄호 `[]` 안에 들어가야 합니다.
|
|
||||||
`type` MUST be enclosed in square brackets `[]`.
|
|
||||||
- `short description` 에는 작업 내용을 **간단하고 명확하게** 한 줄로 작성합니다.
|
|
||||||
`short description` MUST 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 (상위 우선순위 타입)
|
|
||||||
|
|
||||||
1. `[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`
|
|
||||||
|
|
||||||
2. `[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]`
|
|
||||||
|
|
||||||
3. `[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]`
|
|
||||||
|
|
||||||
4. `[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]`
|
|
||||||
|
|
||||||
5. `[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 (일반 변경 타입)
|
|
||||||
|
|
||||||
6. `[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`
|
|
||||||
|
|
||||||
7. `[perf]` – **성능 개선 (Performance)**
|
|
||||||
- 성능 최적화, 메모리/지연 시간 감소.
|
|
||||||
Performance improvements (latency, memory, throughput).
|
|
||||||
- 예 / Examples:
|
|
||||||
- `[perf] reuse dtls buffers`
|
|
||||||
- `[perf] reduce log allocations`
|
|
||||||
|
|
||||||
8. `[docs]` – **문서 (Documentation)**
|
|
||||||
- README, ARCHITECTURE, 주석 등 문서 변경.
|
|
||||||
Documentation changes (README, ARCHITECTURE, comments).
|
|
||||||
- 예 / Examples:
|
|
||||||
- `[docs] add ko/en README`
|
|
||||||
- `[docs] update architecture handshake flow`
|
|
||||||
|
|
||||||
9. `[test]` – **테스트 (Tests)**
|
|
||||||
- 유닛/통합 테스트 추가/수정.
|
|
||||||
Adding or updating tests.
|
|
||||||
- 예 / Examples:
|
|
||||||
- `[test] add dtls handshake unit tests`
|
|
||||||
- `[test] fix flaky proxy integration test`
|
|
||||||
|
|
||||||
10. `[build]` – **빌드/도구 (Build / Tooling)**
|
|
||||||
- Makefile, Dockerfile, CI 스크립트 등 빌드 파이프라인 관련.
|
|
||||||
Build pipeline changes (Makefile, Dockerfile, CI).
|
|
||||||
- 예 / Examples:
|
|
||||||
- `[build] add dockerfile for server`
|
|
||||||
- `[build] update make targets for client`
|
|
||||||
|
|
||||||
11. `[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 (선택적 / 특수 타입)
|
|
||||||
|
|
||||||
12. `[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]`
|
|
||||||
|
|
||||||
13. `[revert]` – **이전 커밋 되돌리기 (Revert)**
|
|
||||||
- 이전 커밋을 되돌리는 경우.
|
|
||||||
Reverts a previous commit.
|
|
||||||
- 예 / Examples:
|
|
||||||
- `[revert] revert dtls handshake change`
|
|
||||||
|
|
||||||
14. `[wip]` – **작업 진행 중 (Work in Progress)**
|
|
||||||
- 미완료 상태의 임시 커밋 (가능하면 main/master에는 남기지 않기).
|
|
||||||
Work-in-progress commits (avoid keeping them on main/master).
|
|
||||||
- 예 / Examples:
|
|
||||||
- `[wip] refactor proxy routing table`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 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]`
|
|
||||||
|
|
||||||
- 포트/리스너 동작 변경 (Port / listener behavior change)
|
|
||||||
- 기본 포트 변경, TLS/DTLS 포트 매핑 변경 등.
|
|
||||||
Changing default ports, TLS/DTLS mapping, etc.
|
|
||||||
- 예 / Example:
|
|
||||||
- `[config] change default dtls port to 8443 [BREAK]`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 4. 요약 (Summary)
|
|
||||||
|
|
||||||
- 커밋 메시지는 항상 다음 형식을 사용합니다:
|
|
||||||
Always use this format for commit messages:
|
|
||||||
```text
|
|
||||||
[type] short description [BREAK]
|
|
||||||
```
|
|
||||||
- `type` 은 위에서 정의한 타입 중 하나를 사용합니다.
|
|
||||||
`type` MUST 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.
|
|
||||||
75
COMMIT_MESSAGE.md
Normal file
75
COMMIT_MESSAGE.md
Normal file
@@ -0,0 +1,75 @@
|
|||||||
|
## Commit Message Requirements
|
||||||
|
|
||||||
|
- A commit message consists of a **title** and an optional **body**.
|
||||||
|
|
||||||
|
### 1. Commit Title Format
|
||||||
|
|
||||||
|
- The commit title must follow this format:
|
||||||
|
|
||||||
|
```text
|
||||||
|
[type] short summary of main change [BREAK]
|
||||||
|
```
|
||||||
|
|
||||||
|
- `type` is enclosed in square brackets (`[` `]`) and describes the nature of the change. For example:
|
||||||
|
|
||||||
|
- `[feature]` : new feature
|
||||||
|
- `[fix]` : bug fix
|
||||||
|
- `[docs]` : documentation changes
|
||||||
|
- `[refactor]` : refactoring without behavior change
|
||||||
|
- `[test]` : tests added or updated
|
||||||
|
- `[chore]` : build, config, or other maintenance tasks
|
||||||
|
|
||||||
|
- You may introduce additional types if needed, following the same `[type]` pattern.
|
||||||
|
- The text after the type is a **concise, one-line summary of the most important change**.
|
||||||
|
- Keep the title **under 72 characters**.
|
||||||
|
- Use **present tense** in the title.
|
||||||
|
- e.g. `add`, `fix`, `update`, `refactor` (not `added`, `fixed`)
|
||||||
|
|
||||||
|
### 2. BREAK Suffix
|
||||||
|
|
||||||
|
- If the commit introduces a **breaking change** (for example, variable renames, API signature changes, or anything that breaks backward compatibility), add the `[BREAK]` suffix at the end of the title.
|
||||||
|
|
||||||
|
```text
|
||||||
|
[feature] add new auth middleware [BREAK]
|
||||||
|
[refactor] rename core config struct [BREAK]
|
||||||
|
```
|
||||||
|
|
||||||
|
- If there is no breaking change, do **not** add `[BREAK]`.
|
||||||
|
|
||||||
|
### 3. Commit Body
|
||||||
|
|
||||||
|
- The commit body should **briefly describe the key changes in the edited files**.
|
||||||
|
- A bullet list is recommended:
|
||||||
|
|
||||||
|
```text
|
||||||
|
- describe change 1
|
||||||
|
- describe change 2
|
||||||
|
- summarize changes per file or module
|
||||||
|
```
|
||||||
|
|
||||||
|
- Focus on **what changed and why**, rather than low-level implementation details.
|
||||||
|
- If there are security or privacy-related changes, explicitly mention them.
|
||||||
|
|
||||||
|
### 4. Examples
|
||||||
|
|
||||||
|
- Without breaking changes:
|
||||||
|
|
||||||
|
```text
|
||||||
|
[feature] add support for local proxy client
|
||||||
|
|
||||||
|
- add CLI flags for local proxy configuration
|
||||||
|
- implement basic request forwarding logic
|
||||||
|
- update documentation with usage examples
|
||||||
|
```
|
||||||
|
|
||||||
|
- With breaking changes (e.g., renaming variables or structures):
|
||||||
|
|
||||||
|
```text
|
||||||
|
[refactor] rename db config fields for clarity [BREAK]
|
||||||
|
|
||||||
|
- rename DSN to DatabaseURL in the config struct
|
||||||
|
- update all references in store and CLI packages
|
||||||
|
- adjust environment variable parsing logic
|
||||||
|
```
|
||||||
|
|
||||||
|
This guideline preserves the original project’s requirements (present tense, short main-change summary, explicit BREAK marking) while adapting the format to use `[type]` commit prefixes.
|
||||||
Reference in New Issue
Block a user