📝 Git Message Convention에 대한 생각
실무에서 협업이 많아지고, 일정에 따라서 서로의 프로젝트를 바꿔가면서 진행하기도 하기에
프로젝트의 흐름 및 변경점에 대한 History의 빠른 파악에 필요한 전략인
Git Message Convention에 대하여 개념을 정리하고자 한다.
📝 Git Message Convention 란 ?
■ 정의
프로젝트의 흐름 및 변경점을 빠르게 파악하기 위하여 Commit Message 를 Udacity Style Guide 에 맞춰서 작성하는 전략
📝 Udacity Style
미국의 영리 교육 기관으로 온라인 강의를 제공하는 기관인 Udacity 가 Git Commit Message 의 구조를 Subject ( 제목 ), Body ( 내용 ), Footer ( 참조 ) 로 정의하고
구조에 들어가는 내용들을 어떻게 작성하는지 설명해 놓은 것이 Udacity Style Guide 이다.
■ Subject : 제목 - ( 필수 )
✒️ 1. 작성법
- 길이는 50자 이하로 작성한다.
- 동사원형( ex. Feat, Fix, Docs, Comment )로 시작한다.
- 첫 글자는 대문자이다.
- 제목의 끝에는 마침표를 붙이지 않는다.
🔗 2. 동사원형
| 이름 | 설명 |
|---|---|
| Feat | 새로운 기능을 추가 |
| Fix | 버그 수정 |
| Design | CSS & SCSS 등 사용자 UI 디자인 변경 |
| HotFix | 급하게 치명적인 버그를 수정 |
| Style | 코드 포맷 변경, 세미콜론 누락, 코드 수정이 없는 경우 |
| Refactor | 프로덕션 코드 리팩토링 |
| Comment | 필요한 주석 추가 및 변경 |
| Docs | 문서 수정 |
| Test | 테스트 추가, 테스트 리팩토링 ( 기능 변경 X ) |
| Chore | 빌드 테스트 업데이트, 패키지 매니저 설정 ( 기능 변경 X ) |
| Rename | 파일 혹은 폴더명 수정 & 이동 |
| Remove | 파일 삭제 |
■ Body : 내용 - ( 필수 )
✒️ 1. 작성법
- 한 문장 당 길이는 72자 이하로 작성한다.
- ( CLI 명령어 실행 시 ) Subject 과 Body 사이에는 한 줄의 공백을 추가한다.
- Commit Message 의 What 과 Why 에 대해 작성하며 How 에 대한 사항을 작성하지 않는다.
■ Footer : 참조 - ( 선택사항 )
✒️ 1. 작성법
- 문제가 된 Commit 의 ID를 작성한다.
- 해결한 Issue 의 ID를 작성한다.
- 문제가 해결 하기 위해 참고한 Commit 의 ID를 작성한다.
- 관련된 팀원들의 ID를 작성한다.
📌 마무리
협업에 있어서도, 여러개의 프로젝트를 다수의 인원이 진행함에 있어서도
프로젝트 흐름 History 파악과 Issue 파악의 가장 빠른 방법이 될 수 있다고 생각하기에
실무에서 반드시 사용해야되는 전략 중 하나라고 생각한다.
개발도중에 신경써서 커밋메세지를 쓰는 것이 귀찮은 사항일 수도 있지만
나 혼자 하는 개발이 아니기에 귀찮음을 감수하고서라도 지키는게 좋을 것 같다.
알고 있는 것을 정리하고, 새로운 것을 알기위해 끄적이는곳..