커밋 컨벤션
When
Git의 커밋 로그에 대한 팀의 접근 방식을 일치 시키고 자 할때
Why
- 커밋 기록 구조화로 프로젝트의 일관성 유지 필요
- 협업관리툴(READMINE)과 연계 할 수 있는 전략이 필요
What
커밋 룰 예시
- 레드마인에서 티켓을 발행
- 티켓에 해당 하는 개발 진행
- 개발 완료시 티켓 발행 번호로 커밋
- 개발 완료후 버그 발생시 레드마인에서 버그 티켓을 발행후 2-3 진행
- 간단 한 수정의 경우에 티켓을 발행하지 않는 경우는 이슈번호를 생략
[이슈번호] [커밋타입]: [메시지]
#1000 Feat: 방어기지 룰 추가
#1001 Fix: 방어기지 생성 룰 수정
#1002 Refactor: 사용하지 않는 라이브러리 삭제
#1003 Chore: 패키지 매니저 Log라이브러리 추가
How
아래 룰을 참고 하여 커밋
기본 전략
- Git Flow 브랜치 전략 을 사용한다.
- 기본적으로 develop 브랜치에서 작성하며 마스터로 바로 커밋하지 않는다.
- 논리적으로 구분되며 일관성이 유지되는 단위로 쪼개서 한다. 예를 들어 작업후 리펙토링을 할경우 작업 커밋과 리팩토링 커밋을 나눈다.
- 세분화된 커밋은 나중에 마스터로 병합할 시 스쿼시(squash)를 통해서 정리 한다.
커밋 타입
- Feat: 새로운 기능의 추가
- Fix: 버그 수정
- Docs: 문서 수정
- Style: 스타일 관련 기능(코드 포맷팅, 세미콜론 누락, 코드 자체의 변경이 없는 경우)
- Refactor: 코드 리펙토링
- Test: 테스트 코트, 리펙토링 테스트 코드 추가
- Chore: 빌드 업무 수정, 패키지 매니저 수정(ex .gitignore 수정 같은 경우)
커밋 메시지 규칙
- 제목과 본문을 빈 행으로 구분
- 제목을
50글자 내로 제한 - 제목 첫 글자는 대문자로 작성
- 제목 끝에 마침표 넣지 않기
- 제목은 명령문으로 사용하며 과거형을 사용금지
- 본문의 각 행은 '72'글자 내로 제한
- 어떻게 보다는 무엇과 왜를 설명 한다