1. Branch Naming Convention
However, you can simplify even more.
Category
A git branch should start with a category. Pick one of these: feature, bugfix, hotfix, or test.
•
feature is for adding, refactoring or removing a feature
•
bugfix is for fixing a bug
•
hotfix is for changing code with a temporary solution and/or without following the usual process (usually because of an emergency)
•
test is for experimenting outside of an issue/ticket
Reference
After the category, there should be a "/" followed by the reference of the issue/ticket you are working on. If there's no reference, just add no-ref.
Description
After the reference, there should be another "/" followed by a description which sums up the purpose of this specific branch. This description should be short and "kebab-cased".
By default, you can use the title of the issue/ticket you are working on. Just replace any special character by "-".
To sum up, follow this pattern when branching:
git branch <category/reference/description-in-kebab-case>
Plain Text
복사
Examples:
•
You need to add, refactor or remove a feature: git branch feature/issue-42/create-new-button-component
•
You need to fix a bug: git branch bugfix/issue-342/button-overlap-form-on-mobile
•
You need to fix a bug really fast (possibly with a temporary solution): git branch hotfix/no-ref/registration-form-not-working
•
You need to experiment outside of an issue/ticket: git branch test/no-ref/refactor-components-with-atomic-design
2. Commit Naming Convention
For commits, you can combine and simplify the Angular Commit Message Guideline and the Conventional Commits guideline.
Category
A commit message should start with a category of change. You can pretty much use the following 4 categories for everything: feat, fix, refactor, and chore.
•
feat is for adding a new feature
•
fix is for fixing a bug
•
refactor is for changing code for peformance or convenience purpose (e.g. readibility)
•
chore is for everything else (writing documentation, formatting, adding tests, cleaning useless code etc.)
After the category, there should be a ":" announcing the commit description.
Statement(s)
After the colon, the commit description should consist in short statements describing the changes.
Each statement should start with a verb conjugated in an imperative way. Statements should be seperated from themselves with a ";".
To sum up, follow this pattern when committing:
git commit -m '<category: do something; do some other things>'
Plain Text
복사
Examples:
•
git commit -m 'feat: add new button component; add new button components to templates'
•
git commit -m 'fix: add the stop directive to button component to prevent propagation'
•
git commit -m 'refactor: rewrite button component in TypeScript'
•
git commit -m 'chore: write button documentation'
1. Commit Convension 은 왜 필요할까?
커밋 컨벤션을 사용하지 않은 경우
커밋 컨벤션을 적용시키지 않아도 겉보기에는 특정 커밋을 보고 충분히 어떤 내용의 커밋인지 충분히 이해할 수 있다고 생각이 들 수 있습니다. 그러나 Commit Message 가 누적될수록 가독성이 매우 떨어집니다.
또한 1인 프로젝트가 아닌, 협업을 진행해야하는 경우 본인만이 이해할 수 있는 커밋 메시지라면 상황은 더 악화됩니다. 혼자만의 커밋 메시지 규칙을 정하고, 원하는 방식으로 히스토리를 관리한다면 협업시에 유지.보수성이 떨어질 것입니다.
커밋 컨벤션을 적용시킨 결과
따라서 모든 팀원이 충분히 이해할 수 있는 공통적인 커밋 메시지 규약 을 정하고, 가독성을 높어야만 개발 속도도 빨라지고 각자 개발한 코드에 대한 코드 리뷰도 수월해집니다.
2. Commit Message 구조
type(타입) : title(제목)
기본 규칙
•
제목과 본문을 빈 행으로 구분
•
제목은 영문 기준 50글자 이하
•
첫 글자는 대문자로 작성
•
제목 끝에 마침표X
•
제목은 명령문으로 사용, 과거형X
•
본문의 각 행은 영문 기준 72글자 이하
•
어떻게 보다는 무엇과 왜
Type
Type 키워드 | 사용 시점 |
feat | 새로운 기능 추가 |
fix | 버그 수정 |
docs | 문서 수정 |
style | 코드 스타일 변경 (코드 포매팅, 세미콜론 누락 등)기능 수정이 없는 경우 |
design | 사용자 UI 디자인 변경 (CSS 등) |
test | 테스트 코드, 리팩토링 테스트 코드 추가 |
refactor | 코드 리팩토링 |
build | 빌드 파일 수정 |
ci | CI 설정 파일 수정 |
perf | 성능 개선 |
chore | 빌드 업무 수정, 패키지 매니저 수정 (gitignore 수정 등) |
rename | 파일 혹은 폴더명을 수정만 한 경우 |
remove | 파일을 삭제만 한 경우 |
대부분 가장 많이 사용하는 것은 feat와 fix입니다. style, design처럼 로직적인 변화가 없을 경우에 커밋 메세지에 명시해주는 것만으로도 추후 오류를 찾을 때 많은 도움이 됩니다.
타입 뒤에 변경된 함수나 메소드를 직접적으로 명시하기도 합니다.
ex) fix(tab): ...
관련 이슈
사용 시점 | 사용 키워드 |
해결 | Closes(종료), Fixes(수정), Resolves(해결) |
참고 | Ref(참고), Related to(관련), See also(참고) |
관련 이슈 언급은 선택사항입니다.
사용 키워드는 위와같이 다양하며, 팀에서 지정한 키워드를 사용합니다.
3. 활용 예시
커밋 메시지 예시
행위::영어(기능::영어): 커밋 내용::한글
* 모듈을 정의하기 어려우면, 패키지 명(card, setting, webfolder …)으로 작성합니다.
•
기능 관련 변경 내용
◦
feat : 기능 추가, 기능 수정
▪
commit message : feat(mail): ~~ 메일 기능 A 예외 처리 추가
▪
branch name : feat/mail
◦
refactor : 코드 리팩토링 및 성능 개선
▪
commit message : refactor(login): 사용자 로그인 권한 체크 로직 리팩토링
▪
branch name : refactor/login
◦
fix : 버그 수정
▪
commit message : fix(setting): 환경설정 NPE 예외 처리
▪
branch name : fix/setting
▪
commit message : fix(2factor): 2차인증 버그 수정
▪
branch name : fix/2factor
◦
remove : 기능 삭제
▪
commit message : remove(oldadmin): 구 관리자 코드 및 페이지 제거
▪
branch name : remove/oldadmin
•
디자인 ( CSS ) 수정
◦
style
▪
commit message : style(maillist): 메일 리스트 CSS 수정
▪
branch name : style/maillist
•
기타 ( 설정 파일 수정이나 뭔가 애매한 상황 )
◦
chore
▪
commit message : chore(confg): JWT 비밀키 수정
▪
branch name : chore/config
▪
commit message : chore(menual): 사용자 메뉴얼 오탈자 수정
▪
branch name : chore/menual
•
커스텀 로직 수정
◦
행위(고객사 도메인/기능)
▪
commit message : fix(AAA/publiccard): AAA 공용주소록 로직 수정
▪
branch name : fix/AAA/publicard