목차
🐣 Coding Convention
✅ Coding Style
Coding Style 규칙
✅ Naming
1. 코드 네이밍
상수 | 대문자 + 스네이크 네이밍 | TOTAL_DISCOUNT_ACCOUNT = 30000 |
변수 | 카멜케이스, 명사 사용 | ㅤ |
함수 | 카멜케이스. 동사를 맨 처음에 작성 ⇒ 최대한 명확한 이름 짓기! 힘들다면 함수로 분리하기! | getValuefetchUsers, navigateToNextPage |
클래스 | 파스칼 케이스 | ㅤ |
타입 | 파스칼 케이스 | ㅤ |
2. 브랜치 네이밍
타입/기능이름(kebab-case) 으로 작성
- ex) refactor/login-page
3. 파일 네이밍
components, pages | 파스칼 케이스 |
hooks | use prefix (use를 맨앞에 씁니다.) |
utils | 카멜 케이스 |
api | 카멜 케이스 |
types | 카멜 케이스 |
ㅤ | ㅤ |
4. 스타일 네이밍
문자열, 객체 는 대문자
함수랑 삼항연산자 들어가면 카멜케이스
✅ Folder Structure
/src │ App.tsx │ main.tsx │ /api | /assets | /components | /hooks | /pages | /types | /utils
✅ develop merge 방식
PR올렸을 때 1명 이상 approve해야 merge 가능합니다!
+ 리뷰 후 PR 다시 올렸을 때 approve 초기화 합니다!
✅ 코드 리뷰 방식
커뮤니케이션 비용을 줄이기 위한 Pn 룰을 적용하면 좋을 것 같습니다.
Pn 룰
- P1: 꼭 반영해주세요 (Request changes)
- 리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다.
- 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.
- P2: 적극적으로 고려해주세요 (Request changes)
- 작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.
- P3: 웬만하면 반영해 주세요 (Comment)
- 작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다.
- Request changes 가 아닌 Comment 와 함께 사용됩니다.
- P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
- 작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다.
- 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.
- P5: 그냥 사소한 의견입니다 (Approve)
- 작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.
💌 Git Commit Message
Type | 내용 |
feat | 새로운 기능 추가 |
fix | 버그 수정 또는 typo |
refactor | 리팩토링 |
design | CSS 등 사용자 UI 디자인 변경 |
comment | 필요한 주석 추가 및 변경 |
style | 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 |
test | 테스트(테스트 코드 추가, 수정, 삭제, 비즈니스 로직에 변경이 없는 경우) |
chore | 위에 걸리지 않는 기타 변경사항(빌드 스크립트 수정, assets image, 패키지 매니저 등) |
init | 프로젝트 초기 생성 |
rename | 파일 혹은 폴더명 수정하거나 옮기는 경우 |
remove | 파일을 삭제하는 작업만 수행하는 경우 |
docs | 문서를 추가하거나 수정하는 경우 |
- 커밋메시지는
한국어로 작성
- 타입은
소문자로 작성
init은 프로젝트 세팅 시 한정적으로 사용
chore는 프로젝트 설정 변경 시 사용
- 작성 예시 :
git commit -m 'feat: 로그인 버튼 추가"
npm run commit 명령어 사용시 커밋 템플릿 사용 가능
types: [ { value: 'feat', name: 'feat:\tfeature를 추가하는 경우' }, { value: 'fix', name: 'fix:\t코드를 수정하는 경우' }, { value: 'docs', name: 'docs:\t문서를 추가하거나 수정하는 경우' }, { value: 'style', name: 'style:\t코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우', }, { value: 'refactor', name: 'refactor:\t(버그나 기능 추가 X) 코드를 리팩토링하는 경우', }, { value: 'test', name: 'test:\t(프로덕션 코드 변경 X) 테스트를 추가하거나 테스트 리팩토링하는 경우', }, { value: 'chore', name: 'chore:\t 빌드 태스크 업데이트, 패키지 매니저를 설정하는 경우', }, ]
👩💻 Branch Rules
Branch 전략
github flow 전략을 사용한다
브랜치 규칙
✅ 작업 진행 순서
깃허브 이슈 생성
- new issue 클릭
- 이슈 목적에 따라 템플릿 선택
- 이슈 작성
assigness : 해당 이슈를 누가 맡을지 선택 - 생성자 ≠ 작업자 (모르면 비워놔도 됌)
label: 해당 이슈가 어떤 작업과 관련 있는가 - ex) feat, fix, refator…
project: 오프팀 프로젝트 선택
milestone: 이슈에 해당하는 스프린트 선택 (쉽게 말해서 1주차, 2주차, 3주차)
- submit new issue를 클릭해서 이슈 생성!
깃허브 이슈에서 브랜치 생성
- 이슈 클릭
- assign, project status 세팅 후 create a branch 클릭
- 브랜치 이름 변경
- +기본적으로 default branch로 설정한 develop branch를 부모로 가진 브랜치가 생성됨
- 만약 main이나 다른 부모 브랜치로부터 생성하고 싶으면 change branch source 클릭해서 수정)
- 명령어 프로젝트 터미널에 복붙 후 작업 시작~
작업 마친 후 PR
- pr 생성 - 지금은 변경사항이 없지만 나중에는 상단에 pr을 작성하라는 알림이 뜰 꺼임! 일단은 new pull request 클릭
- pr 작성
- close 에 관련된 이슈를 작성하면 PR이 merge 되면서 이슈도 같이 닫힘
- project status done으로 변경
- Merge 할 때 feature 브랜치도 같이 삭제
각 브랜치 설명
✅ 브랜치 공통 규칙
- main: 배포용
- 작업은 각자 브랜치 파서 작업합니다.