🐾 브랜치 전략📌 커밋 메시지 컨벤션🫥 Husky저희는 를 이용해 를 다루고 있습니다.🧩 PR 안에 담길 commit 단위 👋 잠깐 짜잘한 fix, refactor, style, setting .. 는 어떻게 하시는지 궁금하시지 않나요 ?
🐾 브랜치 전략
- 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} 통합 테스트
테스트 코드는 하나의 단위로 합쳐도 무방하다
- eliza test : ${기능 테스트 코드 작성} [단위, 통합]
test : User 단위테스트(repository, service ,controller) test : User 통합테스트 feat : User 기능 개발
👋 잠깐 짜잘한 fix, refactor, style, setting .. 는 어떻게 하시는지 궁금하시지 않나요 ?
해당 기능 개발이나 테스트에 적용하셔도 됩니당
커밋 단위는 권장사항이지 꼭 따라야 하는 것은 아닙니다.
만약 저런 가이드대로 했을 때 한 커밋안에 파일 변경이 너무 많은 것 같은? 느낌이 들면
커밋 단위를 각자 재량 것 나눠서 가독성 좋게 나눠주기만 하면 됩니다.