.png)
커밋 메시지 규칙
커밋 메시지 예시
Feat: "로그인 기능 구현" -> 제목
새로고침 시 로그인 유지 기능 개발 -> 본문
Resolves: #67 -> 꼬리말
Ref: #64
Related to: #33, #34커밋 메시지는 제목과 본문으로 나누어진다! 설명이 충분하다면 제목만으로도 괜찮다 하지만 어떤 변경사항이 있는지 맥락과 설명이 필요하다면 본문 혹은 꼬리말을 활용할 수 있다.
제목(Subject)
Feat: "로그인 기능 구현" -> 제목- 제목과 본문을 한 줄 띄우고 콜론(:)으로 분리
- 제목은 영문 기준 50자 이내로 적기
- 영문 기준 동사(원형)을 가장 앞에 두기. (과거 시제를 사용하지 않기)
- 제목 첫글자를 대문자로 적기
- 제목 끝에
.는 금지 - 제목은 명령어, 개조식으로 작성
제목에 대한 표
| 제목 태그 이름 | 설명 |
|---|---|
| Feat | 새로운 기능을 추가할 경우 |
| Fix | 버그를 고친 경우 |
| Design | CSS 등 사용자 UI 디자인 변경 |
| !BREAKING CHANGE | 커다란 API 변경의 경우 |
| !HOTFIX | 급하게 치명적인 버그를 고쳐야하는 경우 |
| Style | 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우 |
| Refactor | 프로덕션 코드 리팩토링 |
| Comment | 필요한 주석 추가 및 변경 |
| Docs | 문서를 수정한 경우 |
| Test | 테스트 추가, 테스트 리팩토링 (프로덕션 코드 변경 X) |
| Chore | 빌드 테스트 업데이트, 패키지 매니저를 설정하는 경우 (프로덕션 코드 변경 X) |
| Rename | 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우 |
| Remove | 파일을 삭제하는 작업만 수행한 경우 |
본문 (body)
새로고침 시 로그인 유지 기능 개발 -> 본문- 선택사항이기 때문에 모든 커밋에 본문을 작성할 필요는 없다
- 부연설명이 필요하거나 커밋의 이유를 설명할 경우 작성
- 72자를 넘기지 않게 작성
- 본문은 어떻게 변경했는지 보다 무엇을 변경했는지, 왜 변경했는지 에 맞추어 작성
꼬리말 (footer)
Resolves: #67 -> 꼬리말
Ref: #64
Related to: #33, #34- 선택사항이기 때문에 모든 커밋에 꼬리말을 작성할 필요는 없다!
- issue tracker id를 작성할 때 사용
유형: #이슈 번호형식으로 작성- 유형은 다음 중 하나를 사용
유형 예시
| 제목 태그 이름 | 설명 |
|---|---|
| Fixes | 이슈 수정 중 (아직 해결되지 않은 경우) |
| Resolves | 이슈를 해결했을 때 사용 |
| Ref | 참고할 이슈가 있을 때 사용 |
| Related to | 해당 커밋에 관련된 이슈 번호 (아직 해결되지 않은 경우) |
브랜치 이름 형식
| 종류 | 사용패턴 | 특징 |
|---|---|---|
| main | main | 프로덕션 스냅샷, 가장 최신의 배포된 버전 |
| dev | dev | 릴리즈 계획에 따라서 Github에서 기본 브랜치로 지정 |
| feature | feature/이슈번호-이름 or feature/1-branch-name | dev에 병합 |
| hotfix | hotfix/이슈번호 or hotfix/#911 | 메인에 병합 |
Pull request 작성하기
PR 형식
- 코드 컨벤션을 잘 지키기
컨벤션 오류로 인한 불필요한 코멘트는 시간 낭비이기 때문에 지양하는 것이 좋다.
- 리뷰 가이드 잘 작성하기
모든 코드 변경사항에는 의도가 필요하다. 의도치 않게 변경된 부분이 있다면 되돌려 놓아야하고, 줄바꿈과 같이 아주 단순한 변경이라도 그 부분을 리뷰어가 볼 필요가 없다면 "Just line change"와 같은 코멘트를 달아 명시하여 리뷰시간을 줄여줄 수 있을 것이다. 또는 사용된 라이브러리 업데이트가 포함되었다면 해당 라이브러리의 릴리즈 노트 링크나 스크린샷을 첨부하는 것도 좋은 방법이다.
- 작업 중, 리뷰 가능 여부를 잘 명시하기
아직 코드를 작성 중 일때에는 [Wip](Work in Progress)를 타이틀 앞에 추가하고, 만약 작업이 끝났으면 이를 제거하고 review-needed태그를 설정할 수 있다. 한 번 작업을 마쳤다고 끝난 것이 아니기 때문에 리뷰를 반영하는 중에도 이를 반복하여 명시해야한다.
- PR 본문
- 아래는 Github Pull Request의 템플릿으로 지정 후 해당 본문은 삭제하면 된다!
### PR 타입(하나 이상의 PR 타입을 선택해주세요)
-[] 기능 추가
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트
### 반영 브랜치
ex) feat/login -> dev
### 변경 사항
ex) 로그인 시, 구글 소셜 로그인 기능을 추가했습니다.
### 테스트 결과
ex) 베이스 브랜치에 포함되기 위한 코드는 모두 정상적으로 동작해야 합니다. 결과물에 대한 스크린샷, GIF, 혹은 라이브 데모가 가능하도록 샘플API를 첨부할 수도 있습니다.자동으로 PR 템플릿 지정하는 방법
ISSUE 형식
- Issue 제목
[title] / body- 아래 형식을 복사해 Github Issue 템플릿으로 지정 후 해당 본문은 삭제하면 된다!
### Issue 타입(하나 이상의 Issue 타입을 선택해주세요)
-[] 기능 추가
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트
### 상세 내용
ex) Github 소셜 로그인 기능이 필요합니다.
### 예상 소요 시간
-[] `0.5h`
-[] `1h`
-[] `1.5h`
-[] `2h`
-[] `2.5h`
-[] `3h`
### 라벨
- 예상 소요 시간: `E: 1h`
- 그룹: `client`, `server`
- 긴급도: `High`, `Middle`, `Low`ISSUE 템플릿 등록하는 방법
토마토마토