커밋 메시지란?
commit 명령어는 Git 안에 staging 한 후 local repository에 발생한 변화를 저장합니다. commit을 통해 수많은 "변경점"이 생성되는데, 각 변경점에 대한 상세를 커밋 메시지로 추가합니다.
좋은 커밋 메시지를 작성해야하는 이유
팀으로 일할 때나 오픈 소스에 기여할 때 커밋 메시지를 임의로 작성하면 서로가 왜, 어떤 코드를 작성했는지 알수가 없습니다.
잘 작성된 커밋 메시지를 통해 협업중인 개발자들에게 변경점에 대한 배경을 손쉽게 알려줄 수 있습니다. 동일하게 미래의 자신에게도 이전의 변경사항에 대해 쉽게 이해하도록 돕습니다.
결국, 커밋 메시지를 통해 어떤 변화가 왜 만들어졌는지 소통할 수 있고, 이를 통해 개발 및 협업을 효율적으로 할 수 있습니다.
좋은 커밋 메시지 작성하는 법
규칙
- 커밋의 종류를 명시하라.
- 제목과 본문을 빈 행으로 구분한다.
- 커밋 메시지는 whitespace errors를 포함하지 않아야한다.
- 불필요한 구두점을 삭제하라.
- 제목은 50글자 이내로 제한한다.
- 제목의 첫 글자는 대문자로 작성한다. (영어인 경우)
- 제목 끝에는 마침표를 넣지 않는다.
- 제목은 명령문으로 사용하며 과거형을 사용하지 않는다.
- 본문의 각 행은 72글자 내로 제한한다.
- 본문에는 변경 사항과 그 이유를 설명하라.
- 검토자들이 본래 문제를 인지하고 있을것이라 가정하지 말고, 본래 문제를 내용에 추가하라.
- 본인의 코드가 설명이 없어도 괜찮다고 생각하지 마라.
- 어떻게 보다는 무엇과 왜를 설명한다.
- 팀의 정해진 커밋 규칙을 따라라.
작성 예시
(영어의 경우 대문자로) 50자 이내 짧은 요약
만약에 필요하다면 보다 자세한 설명을 여기에 쓴다. 내용은 72자 내외에서 마무리하는 것을 권장한다. 어떤 맥락에서는 첫번째 줄은 이메일의 제목처럼 취급되고 나머지가 본문으로 간주된다. 빈 칸 한 줄은 본문과 요약문 및 제목을 구분하기 위한 것으로 본문 전체를 생략하지 않은 이상 필수로 있어야 한다; rebase같은 도구들은 이 본문과 요약문 사이에 빈 칸 한 줄이 없으면 혼란스러워하는 경우도 있다.
커밋 메세지는 명령형으로 적자: 예를 들어 "Fix bug"로 적어야지 "Fixed bug"나 "Fixes bug"가 아니다. 이러한 관습은 git merge나 git revert와 같은 명령어에 의해 생성된 커밋 메세지와 일치하게 된다.
추가 문장들은 빈 칸 한 줄 뒤에 따라온다.
- 글머리 기호가 있어도 괜찮다
- 글머리는 통상적으로 하이픈(-)이나 별(*) 기호 뒤에 한 칸 띄우는 것으로 사용되고 문단과 문단 사이에는 빈 칸 한 줄을 띄우는 것으로 사용되지만 그 외 다양한 법이 존재한다
- 들여쓰기를 사용하자
이슈 트래커를 사용한다면 가장 마지막에 레퍼런스 번호를 이런 식으로 적자.
Resolves: #123커밋 메시지 구조
타입(스코프): 주제(제목) <- Header
본문 <- Body
바닥글 <- Footer
Header
필수로 작성해야하며, 타입은 생략 가능하다.
타입은 해당 커밋의 성격을 나타내며 아래 중 하나를 기입한다.
| 타입(스코프) | 설명 |
|---|---|
| Feat | 새로운 기능 |
| Fix | 버그 수정 |
| Build | 빌드 관련 파일 수정 / 모듈 설치 또는 삭제 |
| Chore | 자잘한 수정, 유지보수 |
| Ci | CI 설정을 수정 |
| Docs | 문서 수정 |
| Style | 코드 스타일 혹은 포맷 등 |
| Refactor | 코드 리팩토링 |
| Test | 테스트 코드 수정 |
| Perf | 성능 개선 |
Body
Header에서 표현할 수 없는 상세한 내용을 기입한다.
Header만으로 표현 가능하다면, 생략해도 좋다.
Footer
참조 정보를 추가한다.
예를 들어 "Issues #1234" 같은 내용이 있을 수 있다.
생략 가능하다.
마치며
커밋 메시지는 명확하고 의미가 있어야한다.
좋은 커밋 메시지를 작성하여 좋은 팀원이 되고 미래의 나와 미래의 동료에게 도움이될 수 있다.
참조
🚙 HMG SOFTEER 3rd | 💻 BE