사실 지금까지 커밋 메시지의 형식에 대해 크게 제약을 걸어본 적이 없다. 혼자 프로젝트를 하기도 했고 내가 쓰다보니 그냥 써도 대충 알아볼 수 있었다. 하지만 이번 미션에서 요구 사항에 커밋 메시지 작성에 조금은 제약이 있었다. 그래서 이번 미션을 통해서 커밋 메시지의 형식에 대해서도 정형화 하려고 한다.
참고 문헌: AngularJS Git Commit Message Conventions
영어라 어려워보인다. 영어공부 열심히해야겠다...
우선 모든 커밋 메세지의 줄은 100자를 넘어선 안된다. 이건 다양한 깃허브 툴에서 보다 더 쉽게 읽게 할 수 있다고 한다. 다른 곳에선 72자라고도 이야기 한다.
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>Subject line
Subject line은 변경 내용의 간결한 설명을 포함한다.
type 허용 내용
타입은 다음 메시지를 허용한다.
- feat (feature) : 새로운 기능 추가
- fix (bug fix) : 버그 수정
- docs (documentation) : 문서만 변경하는 경우
- style (formatting, missing semi colons, ...) : 코드의 의미에 영향을 미치지 않는 변경 사항
- refactor : 버그를 수정하거나 기능을 추가하지 않는 코드 변경
- test (when adding missing tests) : 누락된 테스트 추가 또는 기존 테스트 수정
- chore (maintain) : 패키지 매니저 설정할 경우, 코드 수정 없이 설정을 변경
이 외에도 여러가지가 있다.
scope 허용 내용
- 변경한 커밋 장소
- 예시: $location, $browser, $complie, $rootScope, ngHref, ngClick, ngView, etc...
subject 주의사항
- 현재형, 명령형으로 적을 것(예: change 가능, changes 안됨)
- 첫 글자를 대문자로 적지 말 것
- 마지막에 "."을 붙이지 말것
body
- 현재형, 명령형으로 적을 것(예: change, changes 안됨)
- 변경한 이유를 적어야 하는데, 이전 커밋과 대조하여 서술해야함
footer
모든 breaking change들은 footer에 반드시! 적혀야한다. 근데 이제 변경, 정당성에 대한 설명과 migration note를 곁들인
Breaking changes?
읽는데 여기서부터 막혔다. 찾아보니 한국어론 단절적 변경이라고 한다.
단절적 변경이란, 이 변경으로 인해 다른 것에 영향을 끼칠 수 있는 변경을 이야기 한다.
예를 들면 hello라는 변수를 더 이상 사용하지 않는다던지, addList()라는 메서드가 addListFirst()로 변경되었다던지 하는 내용들이다.
migration?
migration은 IT분야에서는 운영환경을 변경하는걸 이야기 한다. 예로는 MySql을 사용하다가 MongoDB로 넘어가는 상황이 있다.
다시 한 번 footer에 적어야 할 내용을 확인해보겠다.
- foot에는 breaking change를 반드시 적어야한다.
- 변경과 정당성, 그리고 운영환경 변화에 대한 설명은 추가로 작성하면 된다.
위 정리한 내용을 바탕으로 커밋 메시지 템플릿을 만들었다.
- feat (feature) : 새로운 기능 추가
- fix (bug fix) : 버그 수정
- docs (documentation) : 문서만 변경하는 경우
- style (formatting, missing semi colons, ...) : 코드의 의미에 영향을 미치지 않는 변경 사항
- refactor : 버그를 수정하거나 기능을 추가하지 않는 코드 변경
- test (when adding missing tests) : 누락된 테스트 추가 또는 기존 테스트 수정
- chore (maintain) : 패키지 매니저 설정할 경우, 코드 수정 없이 설정을 변경
feat | fix | docs | style | refactor | test | chore ($scope): [subject]
- 현재형, 명령형으로 적을 것(예: change 가능, changes 안됨)
- 첫 글자를 대문자로 적지 말 것
- 마지막에 "."을 붙이지 말것
[body]
- 현재형, 명령형으로 적을 것(예: change, changes 안됨)
- 변경한 이유를 적어야 하는데, 이전 커밋과 대조하여 서술해야함
[footer] - 선택
- foot에는 breaking change를 반드시 적어야한다.
- 변경과 정당성, 그리고 운영환경 변화에 대한 설명은 추가로 작성하면 된다. ++
IntelliJ에 "Git Commit Message Format" 이라는 플러그인이 있었다. 이를 통해서 보다 더 편리하게 커밋 메시지 형식을 지킬 수 있었다.
