[Git/GitHub] Git Commit Convention, 깃 커밋 규칙

📌 Commit Convention

 

🧐 Commit Rules

---

1. 커밋을 잘게 쪼개자 - 커다란 커밋보단 너무 상세하더라도 작은 커밋이 더 낫다.
2. 복잡한 커밋 보단 간단한 커밋 - 한 커밋의 한 파일에서 2가지 액션이 들어가는 순간, 해당 커밋은 복잡한 커밋이 된다. (커밋의 type을 섞지 말자)
3. 원격 저장소에 수시로 push - 내 작업물을 수시로 서버에 push해 다른 사람들이 확인할 수 있도록 한다.

 

📃 Commit Message 구조

---

Udacity Nanodegree Style Guide

Udacity Nanodegree Style Guide

 

커밋 메시지 구조는 제목, 본문(선택), 꼬리말(선택) 세 부분으로 작성한다.

Type: Subject(제목)

Body(본문)

Footer(꼬리말)

 

📌 Type Rule

---

Tag Name	Description
feat	새로운 기능 추가
fix	버그 수정
docs	문서 수정
style	코드 포맷 변경, 세미콜론 누락, 코드 변경이 없는 경우
refactor	프로덕션 코드 리팩토링
test	테스트 코드 추가, 리팩토링 테스트 코드 추가, 프로덕션 코드(실제로 사용하는 코드) 변경이 없는 경우
design	CSS 등 사용자 UI 디자인 변경
init	프로젝트 초기 생성
rename	파일 혹은 폴더명을 수정하거나 옮기는 작업만 수행하는 경우
remove	코드(파일)를 삭제하는 작업만 수행하는 경우
comment	필요한 주석 추가 및 변경
chore	위에 걸리지 않는 기타 변경사항(빌드 스크립트 수정, assets image, 패키지 매니저 등), 관리, 핵심 내용은 아닌 잡일 등

 

🖇️ Subject Rule

---

1. 제목은 50자 이내로 작성
2. 첫 글자는 대문자, 명령문 사용
3. 마침표 및 특수 문자는 사용 X
4. 개조식 구문으로 작성 (간결하고 요점적인 서술)

 

✏️ Body Rule

---

1. 한 줄당 72자 이내로 작성
2. 최대한 상세히 작성 (코드 변경의 이유를 명확히 작성할수록 좋다)
3. 어떻게 보다는 무엇을, 왜 변경했는지에 대해 작성

 

✒️ Footer Rule

---

1. 이슈 트래커 ID 작성
2. 이슈 트래커 유형: #이슈번호 형식으로 작성
3. 여러 개의 이슈 번호는 ,로 구분
4. 이슈 트래커 유형은 다음 중 하나를 사용

이슈 트래커 유형	설명
Related to	해당 커밋에 관련된 이슈 번호 (아직 해결되지 않은 경우) - PR 시 자동으로 이슈 닫히지 않음
Resolves	이슈를 해결한 경우 - PR 시 자동으로 이슈 닫힘
Ref	참조할 이슈가 있는 경우 - PR 시 자동으로 이슈 닫히지 않음

 

📰 Commit 예시

---

feat: 로그인 기능 추가

필요하다면 더 자세한 설명을 서술한다. 한 줄 당 72자 이내로 작성한다.

이 커밋이 해결한 문제에 관해 설명한다. 어떻게 문제를 해결했는지 설명하기보다는 왜 이런 변화를 만들었는가에 집중한다. ("어떻게"는 코드가 설명한다.)
이 내용을 여기에서 설명한다.

문단을 더 추가하고 싶다면 문단 사이에 빈 행을 넣는다.

- 개조식 서술도 괜찮음
- 블릿(bullet)으로 하이픈(-)이나 별표(*)를 사용하고, 한 칸의 공간을 띄고 시작하며, 각 항목 사이 빈 행을 넣는 방식이 일반적이나 다양한 관례가 있음

Resolves: #123
Ref: #456, #789