Git Commit Convention
git 커밋을 작성할 때는 원칙에 맞춰 일관성있게 작성해야만
다른 개발자가 봤을 때에도 커밋이 어떤 메세지를 담고 있는지 명확하게 알 수 있다.
Commit Message 구조
type: Subject //제목
body //본문(내용)
footer //꼬리말
- type : 커밋의 의도
- Subject : 최대 50글자, 마침표는 포함하지 않음, 영문으로 작성시 맨 앞은 동사원형 + 맨 첫글자는 대문자
- body : 최대 72글자, 무엇을 왜 했는지 작성, 긴 설명이 필요할 때에만 작성, 제목과 구분하기 위해서 한 칸 띄고 작성
- footer : Issue Tracker ID를 나타내고 싶을 때 작성 ("유형: #이슈 번호"의 형식으로 작성)
- Fixes: 아직 해결되지 않은 이슈 수정 중
- Resolves: 이슈 해결 시 사용
- Ref: 참고할 이슈가 있을 때 사용
- Related to: 아직 해결되지 않았을 때 해당 커밋에 관련된 이슈번호
Type
Type | 설명 |
Feat | 새로운 기능을 추가할 때 |
Fix | 버그 수정 |
Docs | 문서를 수정한 경우 |
Style | 포맷, 세미콜론, 코드 수정이 없는 경우 |
Refactor | 프로덕션 코드를 수정한 경우 |
Test | 테스트 추가, 테스트 리팩토링, 프로덕션 코드 수정이 없는 경우 |
Chore | 빌드 테스크 업데이트, 패키지 매니저 config 수정, 프로덕션 코드 수정이 없는 경우 |
Design | CSS등 사용자 UI 변경 |
!BREAKING CHANGE | 커다란 API의 변경 |
!HOTFIX | 급하게 치명적인 버그 고쳐야 하는 경우 |
Comment | 주석 추가 변경 |
Rename | 파일 또는 폴더명 수정하거나 옮기는 경우 |
Remove | 파일을 삭제하는 작업만 수행한 경우 |
"타입: 제목"의 형태로 작성한다.
- feat: A new feature
- fix: A bug fix
- docs: Changes to documentation
- style: Formatting, missing semi colons, etc; no code change
- refactor: Refactoring production code
- test: Adding tests, refactoring test; no production code change
- chore: Updating build tasks, package manager configs, etc; no production code change
(참고한 사이트 ❤️🔥)
[협업] 협업을 위한 git 커밋컨벤션 설정하기
들어가며 어떻게 하면 협업을 더 잘할 수 있을까 고민하며 협업에 필요한 내용들을 계속 정리하고 있습니다. 앞으로 저와 함께 협업하는 팀원분들에게 도움이 되고 싶습니다. 이 글은 Udacity Git C
overcome-the-limits.tistory.com
https://udacity.github.io/git-styleguide/
Udacity Nanodegree Style Guide
Introduction This style guide acts as the official guide to follow in your projects. Udacity evaluators will use this guide to grade your projects. There are many opinions on the "ideal" style in the world of development. Therefore, in order to reduce the
udacity.github.io
https://doublesprogramming.tistory.com/256
Git - 커밋 메시지 컨벤션
02_commit_message_rule.md Git - Commit Message Convention 커밋 메시지를 작성할 때는 원칙을 정하고 일관성 있게 작성해야 한다. 아래는 유다시티의 커밋 메시지 스타일 가이드를 참조한 내용이다. 1. Commit..
doublesprogramming.tistory.com