Commit Rules for me

Commit Rule.md

Issues on JIRA

Example

Commit Type: Title [Ticket]

• contents
• contents

Rules

• title starts in CAPITALIZED CHARACTER
• title in english.
• contents in Korean (project by project, discuss with teammates).
• contents, focus on what, why rather than how
• variable, classes should be wrapped by `

Commit Types

• Init 프로젝트 생성
• Feat 새로운 기능 추가
• Fix 버그 수정
• Docs 문서 수정
• Design 디자인 변경
• Style 코드 formatting, 세미콜론(;) 누락, 코드 변경이 없는 경우
• Refactor 코드 리팩토링
• Test 테스트 코드, 리팩토링 테스트 코드 추가
• Chore 빌드 업무 수정, 패키지 매니저 수정
• Minor 사소한 변화

[Ticket] 이 기존 가장 앞부분, 즉 Commit Type 앞 부분에 나왔었는데, 작업하다보니 티켓을 명시하기에는 애매한 커밋들도 존재했다. (Style 타입의 커밋 등)
물론 티켓을 충분히 자세하게 작성하지 못한 책임은 있지만, 통일성을 위해 [Ticket] 을 Title 뒤로 변경한다.

• 기존 : [Ticket] Commit Type: Title
• 변경 : Commit Type: Title [Ticket]

사실 티켓번호는, 코드를 보고 이해가 가지 않는 경우, 혹은 변경 의도&배경을 "참고" 하기 위한 용도로, 코드 자체를 이해하는데는 도움이 되지 않는다.
오히려, Commit Type 은 코드를 보기 전, 어떤 커밋인지를 필터링 하는데에 도움이 되기 때문에 변경된 버전이 훨씬 좋은 것 같다.
사실 매번 업데이트 되는 Oh my Zsh 의 업데이트 콘솔 아웃풋을 보고 떠올린건데, 적용한 이유가 있었겠구나 싶었다.

현재는 Feat 이 너무많은 부분을 차지하는 것 같다.

Component 혹은 위젯 등을 만드는 경우, Feat 이라고도 할 수 있겠지만, 여러곳에서 사용될 수 있다보니 다른걸 추가해도 괜찮을 것 같다.

디렉터리 구조등을 바꾸는 경우에는 어떤 커밋타입을 사용하면 좋을까?

Refactor 를 사용하기에는, 코드변경은 없다보니 잘 어울리지 않는 듯 싶다.
Minor, Chore 등을 혼용해서 사용하고 있었는데, Chore 는 앞으로 디렉터리 위치 변경할때는 사용하지 않아야겠다.
패키지 매니저 수정등에만 사용해야겠음.

추가적으로, 첫번째 줄과 설명 사이에 빈 줄을 추가하도록 한다.

설명에 더해, 꼬리표를 추가해서 설명을 더 하는 경우가 있는데, 이 경우에도 사이에 빈 줄을 추가해주도록 한다. 참고