반응형
개발을 할때 통일성과 빠른 일처리를 위해서 커밋 컨벤션을 정하게됩니다.
따로 저는 이전까지는 생각하면서 커밋하지 않았는데요. 실무상황에서 협업을 하게되면 필수적인 사항이라고 해서 공부해보려합니다. (사실 이번에 메세지 스타일이 있는지 처음 알았습니다..)
커밋 메세지에는 많은 스타일이 있지만 이 글에서는 유다시티 커밋 메세지 스타일을 살펴보겠습니다.
유다시티??
여기서 말하는 유다시티는 미국의 교육 기관입니다. 한국에 우테코, 멋사 같은 느낌인데요.
해당 기관에서 스타일 가이드를 제공하고 있습니다.
커밋 메세지 구조
기본적으로 유다시티 커밋 메세지의 구조는 다음과 같습니다.
Message Type : Subject // 작업 내용을 간단하게 요약해서 기술합니다.
Body // 왜, 무엇을 변경하였는지 기술합니다. 작성하지 않아도 괜찮습니다.
Footer // issue tracker를 사용하는 경우 참조한 issue tracker ID를 기술합니다. 작성하지 않아도 됩니다.
제목에서 Type을 명시하지만, 작성내용을 기술해도되고 안해도됩니다.
커밋 메세지 타입(type)
메세지 구조에 첫번째로 들어가는 type에는 뭐뭐가 있을까요?
- feat : 새로운 기능을 추가하였을 때
- fix : 버그를 수정하였을 때
- docs : README 등 문서 내용을 변경하였을 때
- style : 들여쓰기, 세미콜론 등을 변경하였을 때
- refactor : 코드 리팩토링을 했을 때(기능의 변경은 없어야 한다.)
- test : test코드의 작성 및 수정이 이루어졌을 때
- chore : 외부 라이브러리 임포트 등의 작업을 완료했을 때
다음과 같이 7가지가 있고, 본인이 개발한 작업에 따라서 type을 설정해서 메세지를 작성하시면 됩니다.
타입을 설정하면 제목을 작성해야합니다. 제목은 작성하는 것에 몇가지 규칙이 있는데요.
- 제목은 최대 50글자가 넘지 않도록 하고 마침표 및 특수기호는 사용하지 않는다.
- 영문으로 표기하는 경우 동사(원형)를 가장 앞에 두고 첫 글자는 대문자로 표기한다.(과거 시제를 사용하지 않는다.)
- 제목은 개조식 구문으로 작성한다. --> 완전한 서술형 문장이 아니라, 간결하고 요점적인 서술을 의미.
본문(body)
본문은 작성하지 않아도 되지만, 작성하는 것에 역 몇가지 규칙이 존재합니다.
- 본문은 한 줄 당 72자 내로 작성한다.
- 본문 내용은 양에 구애받지 않고 최대한 상세히 작성한다.
- 본문 내용은 어떻게 변경했는지 보다 무엇을 변경했는지 또는 왜 변경했는지를 설명한다.
꼬리말(footer)
꼬리말 또한 규칙이 존재합니다.
- 꼬리말은 optional이고 이슈 트래커 ID를 작성한다.
- 꼬리말은 "유형: #이슈 번호" 형식으로 사용한다.
- 여러 개의 이슈 번호를 적을 때는 쉼표(,)로 구분한다.
- 이슈 트래커 유형은 다음 중 하나를 사용한다.
- Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
- Resolves: 이슈를 해결했을 때 사용
- Ref: 참고할 이슈가 있을 때 사용
- Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
ex) Fixes: #45 Related to: #34, #23
커밋 메세지 작성에도 협업을 하기에는 알아야할 것이 많은 것 같습니다.
여러분도 같이 커밋 메세지를 유다시티 스타일로 한번 작성해보세요!!
반응형
'Git' 카테고리의 다른 글
git rebase의 장점, merge와 차이 (0) | 2023.03.09 |
---|
댓글