commit convention

commit convention

udacity의 convention을 base로, 세부적인것은 프로젝트에 맞추어 수정하였음

모든 규칙은 서로를 배려하고 이해하기 위해 존재한다!

철학

모든 commit은 더 이상 쪼갤 수 없는 atomic 한 단위로 수행한다.

1. 만약 stage 상태의 파일들이 서로 연관되어 있어 여러 개의 commit으로 쪼개기 힘든 경우,
   roll back 후 다시 atomic한 commit을 만든다.
2. 한 commit에 변경되는 파일의 갯수는 10개가 넘지 않는 것을 지향한다.

다만 아래와 같은 경우는 예외로 한다.

예시)
함수, class의 변경으로 참조하고 있는 다른 파일들도 수정되는 경우.
폴더명이 변경되어 한꺼번에 파일이 삭제되거나 생성되는 경우.
!HOTFIX의 경우.

메시지 구조

메시지는 크게 4가지 영역으로 구성된다.

1. 타입
2. 이유
3. 본문
4. 꼬리말

타입[적용 범위]: 제목 (1줄)
\n
?: 이유 설명 (1줄)
본문(선택 사항)
\n
꼬리말(선택 사항)

한 줄의 길이는 72자 이내로 제한한다.

내부에 이유 등을 list로 표현해야 할 때는 다음과 같이 표현한다.

- 요소 1
- 요소 2

타입

타입은 태그와 제목으로 구성되며, 태그는 영어로 쓰되 첫 문자는 대문자로 한다.

태그

태그는 다음과 같은 종류로 구분된다.

1. 기능
2. 개선
3. 그 외

태그 뒤에는 ": "를 붙여 제목과 구별할 수 있도록 한다.

"태그: 제목"의 형태이며, : 뒤에만 space가 있음에 유의한다.

태그 이름	설명
Feat	새로운 기능을 추가할 경우
Fix	버그를 고친 경우
Design	CSS 등 사용자 UI 디자인 변경
!BREAKING CHANGE	커다란 API 변경의 경우
!HOTFIX	급하게 치명적인 버그를 고쳐야하는 경우
Style	코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Refactor	프로덕션 코드 리팩토링
Comment	필요한 주석 추가 및 변경
Docs	문서를 수정한 경우
Test	테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X)
Chore	빌드 태스크 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X)
Rename	파일 혹은 폴더명을 수정하는 경우
Remove	파일을 삭제하는 경우

자세히 보기

기능

• Feat: 새로운 기능을 추가할 경우
• Fix: 버그를 고친 경우
• Design: CSS등 사용자 UI 디자인 변경
• !BREAKING CHANGE : 커다란 API 변경의 경우
  • API의 arguments, return 값의 변경
  • DB의 테이블 변경
• !HOTFIX: 급하게 치명적인 버그를 고쳐야 하는 경우

추가적인 문맥 정보를 제공하기 위한 목적으로 괄호 안에 적을 수 있다.

예시)
"Feat(navigation):"
"Fix(database):"

BREAKING CHANGE를 사용할 경우, 꼬릿말 Related에 연관 commit 번호를 추가하는 것을 지향한다.

이 변화로 영향을 받는 commit을 파악하기 위함

BREAKING CHANGE이후 변경된 API에 맞춰 수정하는 코드의 commit에는 "Fix"를 붙인다.

개선

• Style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
• Refactor: 프로덕션 코드 리팩토링
  • 새로운 기능이나 버그 수정없이 현재 구현을 개선
• Comment: 필요한 주석 추가 및 변경

Style의 경우 오타 수정, 탭 사이즈 변경, 변수명 변경 등에 해당된다.
Refactor의 경우 코드를 리팩토링 하는 경우 해당된다.

그 외

• Docs: 문서를 수정한 경우
• Test: 테스트 추가, 테스트 리팩토링 (프로덕션 코드 변경 없음)
• Chore: 빌드 태스크 업데이트, 패키지 매니저 설정할 경우 (프로덕션 코드 변경 없음)
• Rename: 파일 혹은 폴더명을 수정하는 경우
• Remove: 사용하지 않는 파일 혹은 폴더를 삭제하는 경우.

Docs의 경우 README.md 수정 등에 해당된다.
Test는 test 폴더 내부의 변경이 일어난 경우에만 해당한다.
Chore의 경우 package.json의 변경이나 dotenv의 요소 변경 등, 모듈의 변경에 해당된다.

제목

코드 변경 사항에 대한 짧은 요약을 나타낸다.

• 제목의 처음은 동사 원형으로 시작한다.
• 총 글자 수는 50자 이내로. (이전 모니터 최대 출력 크기인듯)
• 마지막에 마침표(.)를 붙이지 않는다.

영어의 경우 다음의 규칙을 따른다.

• 영어로 작성할 경우 첫 글자는 대문자로 작성한다.
• "Fix", "Add", "Change"의 명령어로 시작한다.

한글의 경우 다음의 규칙을 따른다.

• "고침", "추가", "변경"의 명령어로 시작한다.

예시)
"수정 변수명"
"Fix typo"
"추가 get data api 함수"

why

이번 commit의 목적과, 어떤 점이 달라졌는지를 설명하는 부분.

1. 태그로 ?: 를 붙인다.
2. 1줄로 요약해서 기술한다.
3. 자세한 내용이 필요할 경우 본문에 개시한다.

예시)
"?: 배열에서 모든 요소를 탐색해야 하므로 reduce로 구현."

본문

커밋의 상세 내용

• 본문은 한 줄에 72자 이내로 작성한다.
• 한 줄을 띄워 문단으로 나누거나 불릿(Bullet, •)을 사용해 내용을 구분한다.
  • 문단을 나눌 시 개행(\n)으로 빈 줄을 추가한다.
• 긴 커밋 본문은 짧은 설명 다음에 위치한다.

꼬리말

꼬리말은 커밋에 대한 메타 정보를 포함한다.

• 관련 있는 PR, 리뷰어, BREAKING CHANGES, 이슈 트래커 ID
• 한 줄에 하나의 메타 정보.

github 이슈 연동

커밋 메시지로 Github 이슈(issue)를 자동 종료시킬 경우 꼬리말에 다음과 같이 서술한다.

키워드 #이슈번호

키워드 종류

1. close
2. closes
3. closed
4. fix
5. fixes
6. fixed
7. resolve
8. resolves
9. resolved

close 계열 : 일반 개발 이슈
fix 계열 : 버그 픽스, 핫 픽스 이슈
resolve 계열 : 문의나 요청 사항에 대응한 이슈

현재 커밋과 관련된 commit 기술

현재 commit과 연관된 commit을 나타내고자 할 때는 다음과 같이 표기한다.

Related: commit번호, commit번호

---

참고) commit 시나리오

commitlint

링크

commitlint를 적용해 타입을 작성할 시 해당 규칙을 지키도록 노력한다.

1. "타입: 제목"을 lint로 검사한다.
2. 통과할 경우 git commit을 수행한다.

commit메시지 작성 툴

commit -m 으로 commit하지 않는다.

1. 72자 제한을 지키기 어려워진다.
2. commit이 길어질 시, 이전 내용을 수정하기 어려워진다.

commit 작성 tool은 이하의 프로그램을 이용한다.

• notepad++ (windows)
  • 열 표식으로 72자 제한을 한다.
• vim

git lg 명령으로 commit log 확인

git log보다는 아래의 커스텀 명령을 추가하는 것을 지향한다.

git config --global alias.lg "log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold red)%h%C(reset) : %C(bold green)(%ar)%C(reset) - %C(cyan)<%an>%C(reset)%C(bold yellow)%d%C(reset)%n%n%w(90,1,2)%C(white)%B%C(reset)%n'"

다음 명령을 추가할 경우, "git lg"를 통해 log를 볼 수 있다.