안녕하세요 오늘은 개발자의 필수 툴 Git 을 사용할 때 적용할 수 있는 대표적인 Git 커밋 메세지 컨벤션 스타일인 유다시티의 스타일에 대해 알아보겠습니다 💪
✏️ Git 을 사용하는 우리
주니어 개발자라면 Git 이라는 도구가 굉장히 낯설고 어렵게만 느껴집니다.
특히 '협업' 은 개발자로써 피할 수 없는 것이고, 그 과정에서 Git을 이용하여 협업을 통해 목표를 달성합니다 👬
그 과정에서 Issue 를 생성하여 서로의 코드에 대한 Comment를 남기기도 하고, PR 을 통해 원작자의 서비스를 개선시키기도 합니다.
우리는 개발 과정에서 개발 목적을 완성하기 위해 수없이 소스 코드를 수정하게 됩니다.
이때, '커밋(Commit)'을 날리게 되는데 해당 커밋을 작성한 개발자 뿐만 아니라 협업하고 있는 다른 개발자들이 이해할 수 있도록 커밋에 대한 메세지를 남겨야 합니다.
이러한 메세지를 '커밋 메세지(Commit Message)'라고 합니다.
커밋 메세지를 작성하고 등록하는 방법에는 여러 컨벤션이 있지만 현재 가장 대중적인 유다시티의 스타일의 커밋 메세지 컨벤션을 공부해보겠습니다 📚
✏️ 유다시티 스타일의 커밋 메세지 컨벤션 구조
유다시티 스타일의 커밋 메세지는 크게 제목, 본문, 꼬리말 세가지 파트로 나뉩니다.
또한 각 파트는 빈줄을 두어서 구분합니다 🧑🏼💻
type : subject (제목)
body : (본문)
footer : (꼬리말)
- type : 어떤 의도로 커밋했는지를 type 에 명시합니다.
- subject : 최대 50글자가 넘지 않도록 하고 마침표는 찍지 않습니다.
영문으로 표기하는 경우 동사(원형)을 가장 앞에 두고 첫 글자는 대문자로 표기합니다. - body : 긴 설명이 필요한 경우에 작성합니다. 무엇을 왜 했는지를 중점으로 작성합니다.
최대 75자를 넘기지 않도록 합니다. - footer : issue tracker ID를 명시하고 싶은 경우에 작성합니다.
✏️ 제목은 어떻게 작성하는가?
📕 타입(Type)
👉 어떤의도로 커밋했는지는 타입에 명시합니다.
유다시티에서는 7개의 타입 중 하나로 쓸 것을 권장 합니다.
| 타입 이름 | 설명 |
|---|---|
| feat | 새로운 기능 추가 |
| fix | 버그 수정 |
| docs | 문서 수정 |
| style | 들여쓰기, 세미 콜론등을 변경하였을때 |
| refactor | 코드 리팩토링을 했을 때 |
| test | test 코드의 작성 및 수정이 이루어졌을 때 |
| chore | 외부 라이브러리 임포트 등의 작업을 완료했을 때 |
📕 제목(Subject)
👉 타입 : 제목 형식으로 사용합니다.
앞에서 설명한 바와 같이 대문자로(영어인 경우) 시작하는 명령형 문장이며 50자를 넘지 않도록 합니다.
또한, 개조식 구문으로 작성합니다 -> 완전한 서술형 문장 x
Feat[type] : 추가 조회 메소드 추가[subject]
✏️ 본문은 어떻게 작성하는가?
👉 본문은 한 줄 당 72자 내로 작성합니다.
👉 본문 내용은 제목과 달리 양에 구애받지 않고 최대한 상세히 작성합니다.
👉 무엇을 왜 변경했는지를 설명합니다.
Feat[type] : 추가 조회 메소드 추가[subject]
< 한줄 띄우고 >
로그인 API 개발[body]
✏️ 꼬리말은 어떻게 작성하는가?
👉 꼬리말은 선택 사항이고 이슈 트래커 ID 를 작성합니다.
👉 꼬리말은 "유형 : # 이슈 번호" 형식으로 사용합니다.
👉 여러 개의 이슈 번호를 적을 때는 쉼표(,) 로 구분합니다.
| 이슈 트래커 유형 | 설명 |
|---|---|
| Fixes | issue 수정중( 아직 해결 안됨 ) |
| Resolves | issue 해결 완료 |
| Ref | 참고할 issue 존재 시 |
| Related to | 해당 커밋에 관련된 이슈 번호( 아직 해결 안됨 ) |
Feat[type] : 추가 조회 메소드 추가[subject]
로그인 API 개발[body]
Resolves: #123 [footer]
Ref: #456
Related to : #100
✏️ 커밋 컨벤션을 지켜야 하는 이유
이번 포스팅을 정리하면서 머릿속에 맴도는 질문이 하나 있었습니다 🤔
굳이 커밋 컨벤션이라는 것까지 만들어서 지켜야 할까?
정리하고 제가 지금까지 기록한 GitHub 커밋을 쭉 살펴보니 중구남방이였으며 보는 처음 보는 사람 입장에서 굉장히 이해하기 힘들 것 같았습니다.
🙁 커밋 컨벤션을 사용하지 않은 경우
해당 이미지는 과거에 진행했던 프로젝트의 커밋 기록입니다.
그 당시에는 커밋 컨벤션이라는 개념을 알지 못했기에 저 혼자 편하게 이해하기 위해 날짜 기준으로 커밋을 했습니다.
어떤가요? 가독성이 매우 떨어지지 않나요?
또한 만약 협업을 하는 팀원 개발자가 진행상황을 확인 하기 위해 제가 기록한 커밋 기록을 볼 때
굉장히 힘들겠죠?
이러한 사소한 문제들은 쌓이다 보면 개발 Output에 큰 영향을 끼칠 수 있습니다 ⛔️
😀 커밋 컨벤션을 적용시킨 결과
어떤가요?
각 커밋의 목적을 한눈에 이해할 수 있겠죠?
이처럼 협업 전에 커밋 컨벤션을 정하고 프로젝트를 진행하면 팀원 간의 코드 리뷰에 도움이 될 뿐 아니라, 자신의 이전 로그를 살펴보는 것에도 도움이 되는 것을 알 수 있습니다 🙆🏻
참고
Git | git 커밋 컨벤션 설정하기
Udacity Git Commit Message Style Guide는 무엇인가
