시작하며,
커밋할 때 커밋 메시지를 어떻게 적어야할까 고민하게 된다
커밋 컨벤션의 존재를 알았지만, 지금까지는 팀프로젝트더라도 클라이언트를 혼자 도맡아서 개발했을 뿐더러, 세부적으로 나누어 커밋하지도 않고 하루 작업물을 밤에 한 번에 커밋하는 형식이었다
회사나 스터디에서는 어느 정도의 규칙이 있고, 그 규칙에 맞게 커밋하면 되어서 커밋 메시지를 큰 고민 없이 적게 된다
이번에 개인 프로젝트를 여러 개 시작하게 되면서, 조금 더 단위별로 나누어서 커밋하려고 노력하고 있다
그러다보니 커밋 메시지를 적는 걸 고민하는 게 은근 피곤해서 (회사에서 커밋할 때는 별 생각 없음) 규칙을 정해보고자 한다
커밋 컨벤션이란?
쉽게 말하면, 커밋 메시지 작성 규칙이다
협업할 때뿐만 아니라, 버그가 생겨서 이전 버전으로 되돌리거나, 어디서 이슈가 터졌는지 트래킹하는 등 유지보수 측면에서도 효과적이다
또한 클린코드를 지향하게 되면, 언젠가 쓰겠지 하고 주석처리하는 대신, 커밋 메시지를 규칙성있게 작성하여, 이후 꺼내쓸 때 커밋 메시지를 보고 찾을 수 있는 장점도 있다고 한다 (물론 본인은 주석처리를 좋아하는 편이지만,,, 클린코드 나도 원해)
Udacity Style
보통 많이 사용하는 Udacity Style을 알아보자
개발자라면, 깃허브의 어딘가에서 한번쯤은 봤을 것이다
기본 구조
type: subject, body, footer 로 나뉘고 각 파트는 한 줄의 공백을 두어 구분한다
type(옵션): [#issueNumber-]Subject // 제목
body(옵션) // 본문
footer(옵션) // 꼬리말[Type] 타입; 어떤 의도의 커밋인가
타입 작성 규칙
- 첫 문자 대문자
- ":" 뒤 공백 한 칸
타입 종류
자주 사용하는
- Feat : 새로운 기능을 추가하는 경우
- Fix : 버그를 고친경우
- Docs : 문서를 수정한 경우
- Style : 코드 포맷 변경, 세미콜론 누락, 코드 수정이 없는경우
- Refactor : 코드 리펙토링
- Test : 테스트 코드. 리펙토링 테스트 코드를 추가했을 때
- Chore : 빌드 업무 수정, 패키지 매니저 수정
- Design : CSS 등 사용자가 UI 디자인을 변경했을 때
- Rename : 파일명(or 폴더명) 을 수정한 경우
- Remove : 코드(파일) 의 삭제가 있을 때. "Clean", "Eliminate" 를 사용하기도 함
기타
- Add : 코드나 테스트, 예제, 문서등의 추가 생성이 있는경우 - Improve : 향상이 있는 경우. 호환성, 검증 기능, 접근성 등이 될수 있습니다.
- Implement : 코드가 추가된 정도보다 더 주목할만한 구현체를 완성시켰을 때
- Move : 코드의 이동이 있는경우
- Updated : 계정이나 버전 업데이트가 있을 때 사용. 주로 코드보다는 문서나, 리소스, 라이브러리등에 사용합니다.
- Comment : 필요한 주석 추가 및 변경
[Subject] 제목; 짧은 요약
제목에는 코드의 변경 사항에 대해 짧은 요약을 적는다
제목 작성 규칙
- 제목은 50자 이하
- 마침표 X
- 명령조로 시작 (한국어도 마찬가지)
- 첫 문자 대문자 (영어인 경우)
added blablabla blablabla blablablabla blabla function. (X)
Add blabla function (O)
블라블라 함수 추가 (X)
추가 블라블라 함수 (O)
[Body?] 본문; 자세한 내용
선택사항
부연설명이 필요하거나, 커밋의 이유를 설명해야할 때 작성
"무엇을 왜 했는지"가 핵심
별도의 규칙은 따로 없는 듯 (정하기 나름)
[Footer?] 꼬리말; For issue tracking
선택사항
꼬리말은 issue tracker ID를 명시할 때 작성
type: issueNum [, ...] 형식으로 작성
issue tracker 유형
- Fixes : 이슈 수정중 (아직 해결되지 않은 경우)
- Resolves : 이슈를 해결했을 때 사용
- Ref : 참고할 이슈가 있을 때 사용
- Related to : 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
Fixes: #45 Related to: #34, #23
커밋 예시
영어 Ver
Feat: Add photo upload function
Add photo upload for photo review
Only one photo can be uploaded
We also change to multi photo upload
Resolves: #30
Ref: #28
Related to: #23, #17한국어 ver
Feat: 추가 사진 업로드 기능
포토 리뷰를 위한 사진 업로드 기능 추가
오직 한 장만 업로드 가능
여러 장 업로드 가능하도록 변경 필요
Resolves: #30
Ref: #28
Related to: #23, #17마치며,
커밋 컨벤션은 본인이나 본인이 속한 팀이 정의하기 나름이며, 회사와 스터디, 프로젝트 모두 커밋 컨벤션이 다 다르다 (물론 통일하는 게 편하겠지만 이상향이기에,,,)
궁극적인 목적은 "알아보기 쉽게, 구분하기 쉽게" 일 테니, 꼭 Udacity Style을 사용할 필요는 없다고 생각한다
그러나 커밋 컨벤션 자체는 필요하다
커밋 컨벤션에 맞게 커밋 메시지를 작성하면 다른 여러 좋은 측면도 있겠지만, 협업할 때 해당 팀에서 어떤 커밋 환경을 가지고 있을지라도 적응할 수 있는 토대가 될 것이다
뿐만 아니라, 커밋 컨벤션이 정의되지 않은 팀이라면 직접 주도적으로 커밋 컨벤션을 정의하고, 도입하여 프로젝트 작업에 약간의 효율을 높일 수도 있지 않을까 싶다 (물론 효율 향상은 개인 역량에 따라 다르다)
