Commit Message Conventions

Generating CHANGELOG.md

changelog에서는 3가지 섹션을 사용한다.

git log <last tag> HEAD --pretty=format:%s

마지막 tag(release) 이후 모든 커밋들의 제목(커밋 메시지의 첫번째 줄)을 가져옴.

git log <last release> HEAD --grep feature

이번 배포버전의 새로운 기능들을 가져옴.

중요하지 않은 커밋 : 로직 변경이 아닌 단순 format 변환, 세미콜론 누락, 주석 등은 중요하지 않다.

이럴 땐 git bisect skip $(git rev-list --grep irrelevant <good place> HEAD) 을 사용해서 무시.

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

<type>
1. feat (feature) : 기능
2. fix (bug fix) : 버그 수정
3. docs (documentation) : 문서
4. style (formatting, missing semi colons, … ) : 스타일 변경 (형식, 세미콜론 누락 등)
5. refactor : 리팩토링
6. test (when adding missing tests) : 테스트
7. chore (maintain) : 빌드, 패키지 관련 (업데이트 등)
<$scope>
1. scope는 커밋 변경 위치를 지정하는 모든 것이 될 수 있다.
  1. $location, $browser, $compile, $rootScope, ngHref, ngClick, ngView, etc
<subject>
1. 명령형으로, 현재 시제 사용 : change(O) → changed(X), changes(X)
2. 첫 글자를 소문자로, 온점 마무리 X
<body>
1. 명령형으로, 현재 시제 사용
2. 변경 이유와 이전 코드와의 차이점 포함
  1. ex) Rename the iVars to remove the common prefix
    1. git rebase -i Head~3 : 헤드부터 3개의 커밋 뒤를 본다.
      
      rebase와 merge는 결론적으로 같다. 하지만 rebase는 공통 조상 커밋에 대한 develop의 차이를 차례대로 패치에 저장하여 master에 적용함으로서 fast-forward 구조를 만들어 한 줄로 깔끔하지만, merge는 두 줄로 나뉘어진 상태로 merge 되므로 rebase가 그래프 상 깔끔하다.
      
      하지만 협업을 하고 있다면 push 하기 전에만 사용하라. 사람들이 사용하는 커밋을 Rebase하면 반드시 문제가 생길 것이다.
    2. reword