Git Commit Message Convention

들어가며

---

오늘 알아볼것은 협업과 커뮤니케이션시 커밋 메시지를 일관성 있고 명확하게 작성하기 위한 규칙입니다, 반드시 따라야 하는 표준이 있는 것은 아니며, 팀에 따라 다르게 정의될 수 도 있습니다, 하지만 널리 사용되고있는 규칙도 존재합니다

 

 

 

Conventional Commits

---

Git 커밋 메시지를 일관되게 작성하는 규칙으로 널리 사용되고있는 규칙입니다

 

규칙의 구조는 다음과 같습니다

<타입> [스코프]: <제목>
[본문]
[바닥글]

 

 

타입

---

커밋의 목적을 나타내는 부분입니다, 아래에서 다루지않는 내용도 있습니다

feat	새로운 기능을 추가할 때 사용합니다
fix	버그를 수정할 때 사용합니다
docs	주석 및 문서 작업시 사용합니다
style	코드 내용에 영향이 없는 변경(서식 등)시 사용합니다
refactor	코드 리팩토링(feat 및 fix에 해당하지않는)시 사용합니다
test	테스트 관련 추가/변경시 사용합니다
perf	성능을 개선하는 코드 변경시 사용합니다

 

 

 

스코프

---

커밋이 영향을 미치는 부분을 명시하는 선택적 요소입니다

타입뒤에 바로 붙으며 괄호로 감싸줍니다, 타입과 스코프 사이, 스코프와 콜론 : 사이의 공백은 없어야합니다

feat(database):
fix(node):

 

 

 

제목

---

변경 사항을 간단하게 요약합니다, 스코프와 함께 사용시 괄호 뒤의 콜론 : 과 제목 사이에 한 칸의 공백을 추가합니다

첫 글자는 소문자로 시작해야 합니다, 제목 끝에 마침표를 찍지 않습니다

feat(auth): add user login feature // 올바른 예시
Feat(auth):Add user login feature. // 잘못된 예시

 

 

 

본문

---

 

커밋의세부사항을 설명하는 부분입니다, 여러줄로 작성 가능하며 제목과 본문 사이에 빈 줄을 삽입합니다

feat(auth): add user login feature

// details
// details

 

 

 

바닥글

---

호환성 문제를 알리거나 커밋이 해결하는 이슈를 명시합니다

// 본문과 바닥글 사이에 한칸 비워주어야함

// 호환성 문제 설명시 BREAKING CHANGE: 대문자로 작성하고 콜론 뒤 한칸 공백

BREAKING CHANGE: details

// 이슈 트래킹시 정확한 이슈 번호를 입력해야함

Closes #000, #001

 

 

 

 

마치며

---

오늘은 Git Commit Message Convention에 대하여 알아보았습니다, 위에서 설명한 커밋 메시지 규칙뿐만 아니라 필요에 따라 상황에 맞게 변형하여 코드의 품질과 협업의효율성을 높일 수 있습니다.