| name | git-convention |
| description | Load when checking the name and label conventions for branches, commits, issues, and PRs. The single source for the three title formats (issue/PR/commit), branch strategy, commit types, and label/assignee rules. The actual execution procedures live in the /commit-push-pr and /create-issue commands. |
Git conventions (daruda)
This file is the single source of truth (SSOT) for name & label conventions. The commands (/commit-push-pr, /create-issue, /resolve-review) hold only procedures and reference here for conventions. Do not copy the contents.
Branch strategy
main ← production deploy (cd-prod.yml)
develop ← dev integration + default branch, PR target (cd-dev.yml)
{type}/#{issue-number} ← working branch
Working branches branch off develop and open a PR to develop.
git switch develop
git pull origin develop
git switch -c feat/#357
Branch names follow the {type}/#{issue-number} format: feat/#355, fix/#302, refactor/#270, chore/#250.
The three title formats — subtly different
Issues have no number, PRs get a number, and only commits use a lowercase type.
| Target | Format | Example |
|---|
| Issue | [{Type}] {Korean description} | [Fix] JWT Token 재발급이 안되는 오류 수정 |
| PR | #{issue-number} [{Type}] {Korean description} | #260 [Fix] JWT Token 재발급이 안되는 오류 수정 |
| Commit | #{issue-number} [{type}] {Korean description} | #260 [feat] 알 수 없는 리프레쉬 토큰 오류메시지 추가 |
- PR title = issue title with
#{issue-number} and a space prepended. Don't drop the number ([Feat] ...) or append it (... (#355)).
- The
Type in issues·PRs is capitalized ([Feat], [Fix], [Chore], [Refactor]); the commit type is lowercase ([feat]).
- The commit type reflects the nature of the commit unit, so it may differ from the 4 issue·PR Types. Example: a
#357 [test] ... commit on a [Feat] issue.
Commit types
| type | Use |
|---|
feat | new feature |
fix | bug fix |
refactor | structural improvement with no behavior change |
test | adding/modifying tests |
chore | build·config·dependency and other incidental work |
style | formatting, semicolons, and other logic-irrelevant changes |
delete | deleting files·code |
Real examples:
#355 [feat] 게시글별 스크랩 수 배치 조회 쿼리 추가
#355 [test] 게시글 목록 응답에 스크랩 수 포함 검증 테스트 추가
#353 [fix] 게시글 목록 조회 시 `size < 1` 입력 방어 로직 추가
#351 [refactor] `ToolService`의 `getLiked` 메서드를 `private`으로 변경
Rules:
- Write the description in Korean, ending in a noun form like
~ 추가, ~ 수정, ~ 변경.
- Wrap code identifiers in backticks:
`BoardService`.
- The issue number includes
#, no brackets, and comes first. (It is not the [#355] feat: ... format.)
- Keep each commit to the smallest self-contained unit — split by kind/concern even within one file. See the Commit granularity section below.
- If a body is needed, write it in Korean after a blank line following the title.
Commit granularity — split to the smallest units
Prefer the smallest self-contained unit that still builds and can be reviewed and reverted on its own. Split whenever changes differ in kind or concern — even when they touch the same file. Sitting in one file is not a reason to combine them.
- Two unrelated bug fixes → two
[fix] commits.
- Different concerns of one issue → one commit each (
[fix] vs [feat] vs [refactor]).
- Production code and its tests → separate commits (
[feat], then [test]).
- Mechanical changes (formatting, renames, import order) → their own
[style]/[refactor] commit, kept out of logic commits.
How, given no interactive staging (git add -p / git add -i are unavailable — see "Git safety rules"): commit incrementally as you write, rather than batching every edit and trying to split afterward.
- Make one logical change.
- Verify (
check-all.sh, or the relevant subset).
- Stage only that change's file(s) (
git add <path>) and commit.
- Repeat for the next change.
When several independent changes get interleaved inside one file, treat that as the signal to stop and commit the current one before writing the next.
Example: a "free-board create" error and an "edit/delete index-lookup" error both live in BoardService, but they are independent bugs → commit them separately (#359 [fix] 자유게시판 작성 오류 수정, then #359 [fix] 게시글 수정·삭제 색인 판단 오류 수정), not as one combined commit.
Labels & Assignee (required on both issues and PRs)
| Item | Value |
|---|
| Type label | one of feat / chore / ⚒️ Fix / 🔥 Refactor |
| Assignee-name label | your own name (예찬, 재민, 지원, 수인) |
| Assignee | yourself (@me) |
Work nature → type label + issue-template mapping:
| Work | Type label | Issue template | Title prefix | Note |
|---|
| New feature | feat | 🛠 Feature | [Feat] | not 📍 Feat |
| Bug fix | ⚒️ Fix | 🔧 Fix | [Fix] | not bug/fix |
| Refactoring | 🔥 Refactor | 🎨 Other | [Refactor] | includes the emoji |
| Config·env·dependency | chore | ⚙ Chore | [Chore] | |
The name labels indicate teammates separately from GitHub accounts. Determine the current user's own name label at runtime (map their GitHub account to one of 예찬/재민/지원/수인); if the mapping is unclear, ask the user rather than guessing. Do not attach someone else's name label arbitrarily.
No commit signatures
Write only the title (+ body if needed) in commit messages. Do not add the trailers below.
❌ Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
❌ 🤖 Generated with Claude Code
The commit author is the actual worker (a teammate); do not credit tools as co-authors. Do not add generation signatures to PR bodies either.
Git safety rules
| Rule | Content |
|---|
| When to commit/push | Only when the user asks. Do not auto-commit just because work is done |
Direct commit to develop/main | Forbidden. Always create a working branch first |
git push --force | Forbidden (--force-with-lease only on user request) |
| Merging your own PR | Forbidden. Only create it, then wait for review |
| Interactive flags | git rebase -i, git add -i, git add -p do not work in this environment (stage per-file and commit incrementally instead) |
.env·secrets | Never commit them. Always check the staged list with git status |
