서론

팀 프로젝트를 하면서, commit message가 잘 읽히게 적히면 좋다고 한 것을 들어 열심히 적어보려고 했지만, 이 convention을 잘 모르던 시기 각자 본인이 생각하기에 잘 정리해서 올려서

다음과 같은 모습을 보이게 됐다. 이점에 문제가 있지 않나? 해서 커밋 메시지 컨벤션에 대해 공부해보게 되었다.

Commit Message Convention

왜 Convention에 맞게 Commit Message를 작성하는가?

하나하나 적을 때는 잘 모르지만, 그냥 메시지에 줄줄이 적어둔 것이 누적되어 쌓여갈수록 한눈에 알아보기가 어려움.

왼쪽이 convention이 없는 경우고, 오른쪽이 convention을 지켜서 적은 경우!

또한 1인 프로젝트가 아닌, 협업을 진행해야하는 경우 본인만이 이해할 수 있는 커밋 메시지라면 상황은 더 악화됨.
혼자만의 커밋 메시지 규칙을 정하고, 원하는 방식으로 히스토리를 관리한다면 협업시에 유지 보수성이 떨어질 것임.

좋은 커밋 메시지 작성법

좋은 커밋 메시지를 작성하기 위해 사용하는 몇 가지 규칙에 대해서 정리해보려고 한다.

Commit Message의 구성

type: subject

body

footer

Commit 유형 예시 (Type에 들어갈 내용)

• feat: 새로운 기능 추가
• fix: 버그 수정
• style: 코드 포맷팅, 세미콜론 누락, 코드 변경 없는 경우
  • 코드 의미에 영향을 주지 않는 변경 사항
• chore : 빌드 부분 혹은 패키지 매니저 수정 사항 (ex .gitignore 수정 같은 경우)
• rename : 파일명(or 폴더명)을 수정한 경우
• remove : 코드(파일) 의 삭제가 있을 때. "Clean", "Eliminate" 를 사용하기도 함
• add : 코드나 테스트, 예제, 문서등의 추가 생성이 있는경우
• improve : 향상이 있는 경우
  • 호환성, 검증 기능, 접근성 등이 될 수 있음
• implement : 코드가 추가된 정도보다 더 주목할 만한 구현체를 완성 시켰을 때
• move : 코드의 이동이 있는 경우
• updated : 계정이나 버전 업데이트가 있을 때 사용
  • 주로 코드보다는 문서나, 리소스, 라이브러리 등에 사용
• comment : 필요한 주석 추가 및 변경
• docs: 문서 수정
• test : 테스트 코드 추가
• refactor : 코드 리팩토링

제목 행에 대한 내용 (Type 옆 콜론 뒤에 적힐 내용)

• 제목 행을 50자로 제한
  • 강제로 제한하는 것은 아니고 읽기 쉽고 간결하게 표현하기 위한 경험에 의한 규칙이다
• 제목 행의 첫 글자는 대문자로 시작
  • readme file modification X
  • Readme file modification O
• 제목 행 끝에 마침표를 넣지 않는다
  • 제목 행의 끝에는 마침표가 필요 없음
  • 50자 규칙에 따르기 위해서라도 마침표를 넣는 것은 불필요한 공간 낭비!
    • Open the door. X
    • Open the door O
• 제목 행에 명령문을 사용한다

  "명령이나 설명하듯이 작성"

  • 네 방을 치운다 (Clean your room)
  • 문을 닫는다 (Close the door)
  • 쓰레기를 갖다 버린다 (Take out the trash)

본문 행에 대한 내용 (Body에 적힐 내용)

• 본문은 72자마다 끊어 줄을 바꿔주기

• 본문을 사용하여 변경 한 내용과 이유 설명

  • 어떻게 보다는 무엇과 왜를 설명하는 것이 좋다
  • HOW (x), What (O), Why (O)

• 보는 사람(검토자)이 원래 문제가 무엇인지 이해한다고 가정하지 말고 확실하게 설명 추가

  • 내 코드가 직관적으로 바로 파악 할 수 있다고 생각하지 말자

• 팀에서 정한 Commit 규칙을 따르자

꼬릿말에 대한 내용 (Footer에 적힐 내용)

• 꼬릿말은 optional, 이슈 트래커 ID 작성하는데 쓰임!
• 하지만 우리는 issue 칸 사용 안할 것 같기 때문에.. 그냥 흘러가듯이 보면 될듯
• “유형: #이슈 번호” 형식으로 사용
• 이슈 트래커 유형은 다음 중 하나 사용
  • Fixes: 이슈 수정 중 (아직 해결되지 않은 경우)
  • Resolves: 이슈를 해결했을 때 사용
  • Ref: 참고할 이슈가 있을 때 사용
  • Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
    • ex) Fixes: #45 Related to: #34, #23

Feat: "추가 로그인 함수"

로그인 API 개발

Resolves: #123
Ref: #456
Related to: #48, #45

Convention에 맞게 Commit Message 작성법

제목과 본문을 빈 행으로 분리

git commit -m "커밋 제목

부가 설명"

Git Commit Editor

여러 행으로 구성된 커밋 로그를 -m 스위치를 사용해서 입력하기는 어렵다.

commitlint - Lint commit messages

husky와 commitlint 등의 자동화 방법이 있는 것 같지만.. 일단 이 convention부터 차차 익히고 사용해볼까 한다.