Etc.
[Git] Commit Message 규칙
개발자 쓔쓔
2022. 9. 22. 15:04
반응형
Commit
위키백과에 따르면 커밋은 "저장소에 소스 코드의 일부의 최신 변경사항을 추가함으로써 이러한 변경사항을 저장소의 최상위 리비전(head revision)의 일부분으로 만들어주는 것"이라고 한다.
커밋 메시지의 규칙이 없다면
- 나만 알 수 있는 방식으로 커밋 메시지를 보내는 경우, 협업하는 대상자들은 이해가 안 된다.
- 시간이 지날수록 "커밋"은 누적될 텐데, 차후 코드 유지 보수 및 가독성이 떨어질 수 있다.
=> 커밋 메시지의 규칙이 있다라면 협업하는 대상자끼리 대화가 용이하며, 차후 유지보수 관점에서 좋다
커밋 메시지
7가지 규칙
- 제목과 본문을 빈 행으로 구분한다.
- 제목은 50자 이내로 제한한다.
- 제목의 첫 글자는 대문자로 작성한다.
- 제목의 끝에는 마침표를 넣지 않는다.
- 제목은 명령문으로 사용하며, 과거형을 사용하지 않는다.
- 본문의 각 행은 72글자 내로 제한한다.
- 어떻게 보다는 무엇과 왜를 설명한다.
메시지 기본구조
type: subject (#issue)
body
footer많은 곳에서 통용하고 있는 커밋 메시지 방식이다.
첫 줄에 제목 / 두 번째 줄 빈 행 / 세 번째 줄 본문(내용) / 네 번째 줄 빈 행 / 다섯 번째 줄 바닥글로 정의되어있다.
type
- feat : 새로운 기능 구현
- fix : 버그 수정
- build : 빌드 관련 파일 수정 (appspec.yml, afterInstall.bash ...)
- docs : 문서 수정 (Readme.md, .gitignore.. )
- style : 코드 스타일 혹은 포맷에 대한 수정
- refactor : 코드 리팩토링 진행
- test : 테스트 코드 추가 및 수정
- chore : 그 외 자잘한 수정
- 위의 것 외에 (release, ci .. 등이 존재하는 것 같고, type에 대해서는 팀 내에서 추가로 정의하여 진행해도 무방할 것 같다)
subject
- 제목은 50자 이내로 작성하며 , 명령문으로 작성하며 마침표로 끝나지 않습니다 ( 영문으로 기입 시 첫 글자는 대문자로 시작합니다.)
- 제목 뒤에는 특정 이슈를 참조할 수 있습니다. (#이슈번호) -> Ex. fix: 회원별 회원가입 유효성 변경 (#123)
body
- 제목에 작성된 내용에 대해서 상세한 내용이 필요하다면 작성합니다.
- 제목을 통해 해당 커밋에 대해서 설명이 된다라면 작성하지 않아도 됩니다.
footer
- 본문과 마찬가지로 작성하지 않아도 무방합니다.
- 일반적으로 이슈를 추적하기 위해서 이슈 번호를 넣어주는 용도로 사용됩니다.
- 해결: #123 // 관련 #123 // 참고 #123
마무리
일단 커밋 메시지부터 정의하는 것으로 시작을 해보자.
하나의 기능이 하나의 커밋에 들어가는 것이 원칙적인데 이것도 뜯어나가야 하는 숙제이지 않을까. (시스템을 도입하기 이전 서로가 편한 방식대로 진행을 한 게 폐해다...)
Git flow형태의 브랜치 관리 변경도 진행하긴 해야 할 것 같은데 이것도 하나의 숙제.
참고 사이트
https://github.com/angular/angular
728x90
반응형