Commit 컨벤션

📦 Commit 컨벤션

[타입] 제목
# 동사 원형으로 쓰기
# 타입 종류 : fix, docs, style, refactor, test, chore

본문
# 본문의 내용은 어떻게보다는 무엇을 왜에 맞춰 작성한다.

이슈 번호
# 해당 커밋과 연관된 이슈 트래킹 번호

[feat] 친구 화면에서 추가 버튼 구현

XXX 클래스를 사용해서 친구 추가 기능 구현했다. 
친구추가하려면 버튼이 필요하기 때문이다.
- yyy DB에 post 요청
- zzz uri에 요청~~

Closes: #1231

feat: 새로운 기능을 추가하거나 기존의 기능을 요구 사항 변경으로 변경한 경우 기능 추가와 수정을 나누어서 쓰고 싶은 경우 아래 처럼 2개로 나누어서 타입을 지정할 수 있다.
- new: 새로운 기능을 추가 한 경우
- improve: 기존 기능을 수정 한 경우, 요구 사항이 변경되어 수정된 경우에도 improve 타입으로 한다.
fix: 기능상 버그 픽스를 했을 경우
docs: 문서(주석)의 추가/수정의 경우, 직접적인 코드의 변화 없이 순수하게 문서(주석)만 추가/수정했을 경우
style: UI를 추가/변경 하거나 스타일 관련 작업을 했을 경우
refactor: 기능의 변화가 아닌 코드를 리팩토링했을 경우, 코드 리뷰 등으로 로직(기능)의 변화 없이 단순 함수 내부에서만 사용하는 이름을 변경하였거나, 코드 pretty 등을 적용했을 경우
test: 테스트 코드를 별도로 추가하거나, 변경했을 경우, 만약 기능을 추가하면서 테스트 코드를 동시에 작성했으면 feat 타입으로 사용
chore: 기능/테스트 코드, 문서, 스타일, 리팩토링을 제외한, 배포, 빌드 등과 같이 프로젝트의 기타 작업들에 대해 추가/수정했을 경우, lint 등의 적용으로 코드 스타일을 수정 했을 때도 chore 사용
release: 릴리스를 하기 위해 패키지 버전을 올리거나, 릴리스 버전 커밋을 찍기 위한 경우

커밋에서 수정된 상세내역을 작성한다. 여기선 평서문으로 작성하면 된다.
본문은 생략 가능하며, 제목(Subject) 라인과 반드시 한 줄을 띄운다.
되도록 한 줄에는 72자 이하로 작성하고 길어질 경우 개행해서 다음 줄에 입력한다.
- 제목과 마찬가지로 100자 정도까지는 괜찮은 거 같다.
수정 내역을 블릿 기호(*)를 이용해서 하나씩 입력하는 방법도 좋다.
본문의 내용은 어떻게보다는 무엇을 왜에 맞춰 작성한다.
- 본문에는 이 커밋이 무엇을 왜 고쳤는지 적혀 있는 것이 나중에 히스토리 파악하거나, 코드의 변경 의미를 파악하기에 훨씬 도움이 된다.
- 어떻게 고쳐졌는지는 코드의 히스토리를 통해 충분히 파악할 수 있으니 반드시 무엇을 왜 했는지에 대해 작성하도록 한다.