| name | git-conventions |
| description | Use when naming branches, writing commit messages, creating or editing GitHub issues, or creating or editing GitHub pull requests in this repository. |
Git Conventions
이 레포에서 브랜치, 커밋, 이슈, PR을 작성할 때 아래 규칙을 적용한다.
References
- 이슈를 만들거나 수정할 때는
references/issue.md를 읽는다.
- PR을 만들거나 수정할 때는
references/pull-request.md를 읽는다.
Type
브랜치와 커밋의 type은 작업 성격에 맞춰 아래에서 선택한다.
feat
fix
refactor
design
chore
docs
test
ci
build
init
Branch
작업 브랜치는 아래 형식을 사용한다.
<type>/#<issue-number>-<summary>
작성 규칙:
<type>은 소문자로 쓴다.
- type 뒤에는
/를 붙인다.
- 이슈 번호 앞에는
#를 붙인다.
- 이슈 번호와 summary는
-로 구분한다.
- summary는 영어 소문자 kebab-case로 쓴다.
- summary는 작업의 핵심 명사/동사만 짧게 쓴다.
- 여러 단어는 공백 대신
-로 연결한다.
- 여러 이슈를 한 브랜치에서 처리하면 이슈 번호를
,로 이어 쓴다(예: fix/#165,#193-qr-scan).
예:
feat/#217-5th-map-ui
fix/#143-map-bound
refactor/#196-photo-detail-memo-outside-pager
docs/#45-create-md
이슈 번호가 없는 작업은 <type>/<summary> 형식을 쓴다. 릴리즈 브랜치는 release/<version>을 쓴다.
docs/readme
release/1.3.1
Commit
커밋 메시지는 아래 형식을 사용한다.
[<type>] #<issue-number>: <summary>
작성 규칙:
<type>은 소문자로 쓰고 []로 감싼다.
- type 뒤에는 공백 하나를 둔다.
- 이슈 번호가 있으면
#<issue-number>:를 쓴다.
- 이슈 번호와 summary는
: 뒤에 공백 하나를 둔다.
- summary는 한국어로 작업 내용을 구체적으로 쓴다.
- summary는 한 줄로 작성한다.
- summary 끝에는 마침표를 붙이지 않는다.
예:
[feat] #209: UserRepository에 마케팅 팝업 노출 기록 기능 추가
[fix] #211: 푸시 알림 본문이 두 줄 이상일 때 잘리는 현상 수정
[refactor] #210: 포즈 상세 북마크 커밋 상태 관리 정리
이슈 번호가 없는 작업은 이슈 번호 영역을 뺀다.
[docs] README 수정
[chore] RepositoryModule 선언부 interface로 변경
Issue
references/issue.md를 따른다.
Pull Request
references/pull-request.md를 따른다.