> Git 이름 규칙 (repository naming & Message Convention convention)

 

■

1. Git 저장소 이름 규칙 (Repository naming Convention) 

 

▶ 저장소 이름에 사용되는 Keyword는 의미가 분명하고, 고유하게 구별할 수 있도록 작성한다.

▶ 특수 문자 및 공백을 사용하지 않는다.

▶ 저장소 이름 규칙에 사용되는 고유 명사는 대문자로 표기.

▶ 저장소 이름에 사용되는 Keyword의 표기는 카멜표기법을 사용.

      ※ 카멜 표기법 : 소문자를 기본으로 하되 각 단어의 첫글자만 대문자로 지정해 주는 방식 (ex. myLittleApple)

▶  저장소 이름에 사용되는 Keyword 간의 구분은 '하이픈(-)'을 사용.

       ※  대시를 사용하면 단어 사이의 공백을 더 잘 인식하기 때문에 대시로 구분된 단어를 더 쉽게 읽을 수 있다.

▶  저장소 이름 규칙:  프로젝트명-개발환경-개발목적

       ※  특정 개발 환경에서만 프로젝트가 작동되는 경우 그 개발환경을 우선적으로 작성한다.

<<특별히 명명한 프로젝트 명이 없을 경우 도메인(Domaion) 자체가 프로젝트 명이 될 수 있다.>>

http://domain.com ➔ domain.com.git
http://sub.domain.com ➔ sub.domain.com.git

 

▶ (선택 사항) Git 저장소 이름 규칙은 git repository라는 것을 나타내기 위해 git.으로 시작

 

 

■

2. Git  Commit  message 규칙 (Commit Message Convention)

 

(1) 기본 커밋 메시지 구조

제목 (Type: Subject)
(한줄 띄어 분리)
본문 (Body) 
(한줄 띄어 분리)
꼬리말 (Footer)

 

 

(2) 커밋 메시지 Tag 

 

Feat :  새로운 기능 추가

Fix  :  버그 수정

Design :  CSS 등 사용자 UI 디자인 변경
!BREAKING CHANGE :  커다란 API 변경의 경우
!HOTFIX :  급하게 치명적인 버그를 고쳐야하는 경우
Style : 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
Refactor : 프로덕션 코드 리팩토링
Comment  : 필요한 주석 추가 및 변경
Docs  : 문서 수정
Test : 테스트 코드, 리펙토링 테스트 코드 추가, 실제로 사용하는 코드 변경 없음
Chore :  빌드 업무 수정, 패키지 매니저 수정, 패키지 관리자 구성 등 업데이트, Production Code 변경 없음
Rename : 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
Remove : 파일을 삭제하는 작업만 수행한 경우

 

(3) 예시 

- header

- body :  코드 변경의  이유 및 변경 부분 작성

- footer : issue tracker ID , 이슈트래커 유형 등 (아래 참고)

Feat: 회원 기능 개발

회원가입 API 개발

Resolves: #1
Ref: #2
Related to: #4, #7

 

 

 

※ Footer 참고

- 생략 가능

-  유형 태그: #이슈 번호

-  복수의 이슈번호는 쉼표(,)로 구분

 ex) Fixes: #1 Related to: #3, #4

 

-  이슈 트래커 유형태그
1. Fixes: 이슈 수정중 
2. Resolves: 이슈를 해결
3. Ref: 참고할 이슈
4. Related to: 해당 커밋에 관련된 이슈번호