커밋 메시지 컨벤션

AngularJS Git Commit Message Conventions에서 제안한 깃 커밋 메시지 컨벤션의 원리와 구조, 실제로 적용하는 방법을 학습하고, 정리했습니다.

이 글을 통해 커밋 메시지를 일관된 형식으로 작성하고, changelog 생성이나 자동 배포에 활용할 수 있습니다.

왜 필요한가?

버그 고침
많이 함
찐막 버전

만약 커밋 메시지가 이런 식으로 남겨져 있다면 어떤 작업을 했는지 감이 오시나요? 무엇을, 어떻게, 왜 했는지에 대한 정보가 하나도 없어서 커밋 메시지만으론 아무 것도 알 수 없고, 결국 변경된 코드를 모두 확인해야 정보를 알 수 있을 것입니다. 확인할 커밋이 많다면 시간이 엄청나게 낭비됩니다.

커밋 메시지 컨벤션을 적용해 작성한다면, 이런 문제를 해결하고 효율성을 높여줄 수 있습니다.

커밋 메시지의 기본 구조

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

전체 구조는 이렇게 이루어져 있습니다. subject, body, footer 하나하나 자세히 살펴보겠습니다.

Subject line

<type>(<scope>): <subject>

subject line은 변경에 대한 간결한 설명을 나타내야 합니다.

type은 커밋의 성격을 나타냅니다. 타입에는 feat, fix, docs, style, refactor 등등이 있습니다.

scope는 변경된 모듈이나 영역을 나타냅니다. 선택 사항이지만 사용하면 더 효과적으로 변경 사항을 전달할 수 있습니다.

subject는 명령형, 현재 시제로 무엇을 했는지 나타냅니다. 첫 글자를 소문자로 쓰고, 마침표를 찍지 않습니다.

subject line의 예시는 다음과 같습니다.

feat(auth): add login feature

Message body

body도 subject와 마찬가지로 명령형, 현재 시제를 사용합니다. subject가 “무엇을”이라면, body는 “왜”와 “어떻게”를 설명하는 곳입니다. 이유, 동기, 과거와의 차이를 서술합니다.

Message footer

footer는 부가적인 정보를 담는 곳입니다. 이슈 참조와 Breaking Change, 이전/이후 코드 예시와 마이그레이션 가이드를 포함합니다.

Breaking changes 예시

BREAKING CHANGE: isolate scope bindings definition has changed and
    the inject option for the directive controller injection was removed.
    
    To migrate the code follow the example below:
    
    Before:
    
    scope: {
      myAttr: 'attribute',
      myBind: 'bind',
      myExpression: 'expression',
      myEval: 'evaluate',
      myAccessor: 'accessor'
    }
    
    After:
    
    scope: {
      myAttr: '@',
      myBind: '@',
      myExpression: '&',
      // myEval - usually not useful, but in cases where the expression is assignable, you can use '='
      myAccessor: '=' // in directive's template change myAccessor() to myAccessor
    }
    
    The removed `inject` wasn't generaly useful for directives so there should be no code using it.

이슈 참조 예시
```
Closes #123, #245, #992
```

Type Reference

feat	기존 코드에 새로운 기능이나 동작을 추가할 때
fix	기존 코드의 오류나 비정상 동작을 고칠 때
docs	README, 개발 가이드, API 문서, 주석 등 문서 관련 내용만 수정할 때
style	코드의 형태나 포맷만 바꾸고 로직은 그대로일 때
refactor	기능 변화 없이 코드 구조나 설계를 개선할 때
test	테스트 코드만 추가, 수정, 삭제할 때
chore	빌드 설정, 의존성 업데이트, 설정 파일 수정 등 기능과 관계없는 작업을 할 때

저는 여기서 style과 refactor가 항상 헷갈리는 포인트였습니다. 그래서 여기저기 찾아보고 스스로 세운 기준은 공백이나, 줄바꿈처럼 코드가 단순하게 보기 쉽게 만들 땐 style을 사용하고, 메서드를 추출하거나, 변수명을 변경하는 등 조금 더 리팩토링스러운 것을 refactor를 사용하는 것입니다.

참고자료

Git Commit Message Conventions

Git 커밋 메시지 컨벤션 완전 정복: 왜, 어떻게, 무엇을 기록해야 하는가