⛏️

Git 컨벤션

 

🐾 브랜치 전략

  • main - 최종 배포 브랜치 입니다.
  • develop - 배포 전 모든 기능 개발, 수정 사항은 해당 브랜치로 Merge됩니다.
  • 이슈ID - 모든 기능 개발, 리팩토링, 버그 픽스 등은 이슈 ID로 생성해서 해당 브랜치에서 작업합니다.
 

📌 커밋 메시지 컨벤션

feat : 새로운 기능 추가
fix : 버그 수정(핵심 비즈니스 로직)
refactor : 코드 구조 변경 및, 네이밍 변경 포함 - (삭제 파일 포함)
style : 마감 처리 , 컨벤션
setting : dependency 설정
test : ${xxxx} 테스트
docs : readme 기능 리스트 추가
 

🫥 Husky

저희는
🚥
GIT - Husky 가이드
를 이용해
🏈
git Hooks
를 다루고 있습니다.

  • 일관된 커밋 규칙을 위해 git hooks를 활용하고 husky를 이용해 프로젝트 단위로 hooks를 관리합니다.
 

🧩 PR 안에 담길 commit 단위

feat: ${기능 개발}
test: ${function} 단위 테스트
test: ${function} 통합 테스트
test : ${기능 테스트 코드 작성} [단위, 통합]
test : User 단위테스트(repository, service ,controller) test : User 통합테스트 feat : User 기능 개발

👋 잠깐 짜잘한 fix, refactor, style, setting .. 는 어떻게 하시는지 궁금하시지 않나요 ?

🍯
해당 기능 개발이나 테스트에 적용하셔도 됩니당
 
⚠️
커밋 단위는 권장사항이지 꼭 따라야 하는 것은 아닙니다. 만약 저런 가이드대로 했을 때 한 커밋안에 파일 변경이 너무 많은 것 같은? 느낌이 들면 커밋 단위를 각자 재량 것 나눠서 가독성 좋게 나눠주기만 하면 됩니다.