Commit message에 대하여
1. 메세지 작성에 규칙이 필요한 이유 : 협업
우리는 Git/Github을 통해 협업을 진행한다. 즉, 한 프로젝트를 여러명이 접근해서 수정할 수 있다는 이야기다.
누군가가 commit을 할 때 개인만 편하게 작성을 한다면, 언젠가 시간이 흐르면 작성자 본인도 알아보기 힘들 것이고, 타인은 당연히 헷갈릴 수 있다.
그렇기 때문에 개발자들 끼리 commit message에 일정한 규칙을 두고 진행하는것이 필요하다.
- 협업자들간 소통
- 기억에 의존하지 않는 기록
- 이슈 트래킹
2. 메세지 구조와 규칙
다음과 같은 규칙을 많이 사용하는 것으로 확인했다.
커밋 메세지 구조
<type>: <subject> -- 헤더 <BLANK LINE> -- 빈 줄 <body> -- 본문 <BLANK LINE> -- 빈 줄 <footer> -- 바닥글헤더 타입
feat : 새로운 기능 추가 fix : 버그 수정 build : 빌드 관련 파일 수정 ci : CI관련 수정 docs : 문서 추가, 삭제, 수정 style : 스타일(로직 변경 없이 코드 스타일)변경 refactor : 코드 리팩토링 test : 테스트코드 추가, 삭제, 수정 chore : 기타 변경사항 (빌드 스크립트 수정 등)커밋 메세지의 규칙
- 제목과 본문을 빈 행으로 구분(바닥글도)
- 제목은 50글자 이내, 타입과 함께 기재
- 제목의 첫 글자는 대문자
- 제목 끝에 마침표를 넣지 않음
- 제목은 명령문 형태
- 본문의 각 행은 72자 이내
- 본문은 어떻게보다 What, Why로 작성
- 본문과 바닥글은 필수 X
- 이슈표기, 바닥글과 관련하여
이슈를 표기하는것이나, 바닥글에 관한 내용은 추후 작업하며 더 알아보기로한다.
오늘 이후 Commit 시에는 공부한 메세지규칙을 따르며 해볼 예정.
가끔 지인 중 개발자들이 위와같이 Commit메세지를 남기는 것을 보고 뭔가 다들 비슷하게 메세지를 남긴다고 은연중에 생각했었는데... 뭔가 궁금증이 해결된 것 같다.
Reference
'공부 > [Git]' 카테고리의 다른 글
| [Git] git/github 브랜치와 push pull관련 내용 (0) | 2022.01.14 |
|---|---|
| [Git]Fork를 통한 협력 그리고 Contributor vs Collaborator (0) | 2022.01.04 |
댓글