commit convention

commit convention

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

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

메시지 구조

메시지는 크게 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 변경의 경우
• API의 arguments, return 값의 변경
• DB의 테이블 변경 추가적인 문맥 정보를 제공하기 위한 목적으로 괄호 안에 적을 수 있다.

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

BREAKING CHANGE를 사용할 경우, 꼬릿말 Related에 연관 commit의 번호를 추가하는것을 지향한다. (이 변화로 영향을 받는 commit을 파악하기 위함) BREAKING CHANGE이후 변경된 API에 맞춰 수정하는 코드의 commit에는 "Fix"를 붙인다.

개선

• Style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
• Refactor: 프로덕션 코드 리팩토링
• 새로운 기능이나 버그 수정없이 현재 구현을 개선
• Comment: 필요한 주석 추가 및 변경 Style의 경우 오타 수정, 탭 사이즈 변경, 변수명 변경 등에 해당된다. Refactor의 경우 코드를 리팩토링 하는 경우 해당된다.

그 외

• Docs: 문서를 수정한 경우
• Test: 테스트 추가, 테스트 리팩토링 (프로덕션 코드 변경 없음)
• Chore: 빌드 태스크 업데이트, 패키지 매니저 설정할 경우 (프로덕션 코드 변경 없음)

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자 이내로 작성한다.
• 한 줄을 띄워 문단으로 나누거나 불렛을 사용해 내용을 구분한다.
• 문단을 나눌 시 \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를 볼 수 있다.