🪛기술 스택
언어 | TypeScript |
라이브러리 | React |
상태관리 | tanstack-query |
전역 상태관리 | recoil |
번들러 | vite |
API | axios |
포맷팅 미정 | eslint, prettier, husky // lint-staged, commitlint, commitizen ⇒ 추가 정보 필요 |
유틸 라이브러리 | React Hook Form |
패키지 매니저 | npm (18.17.1) |
스타일링 | emotion css |
라우터 | react-router |
배포툴 | vercel, aws s3, netilfy |
브랜치 전략 | Github flow |
협업툴 | notion, github, JIRA |
소통 | Slack, Discord(백엔드랑 협의) |
User-story | Figjam |
api test | msw |
ㅤ | ㅤ |
🐣 Coding Convention
▶️ Coding Style
Coding Style 규칙
▶️ Naming
1. 코드 네이밍
상수 | 대문자 + 스네이크 네이밍 | TOTAL_DISCOUNT_ACCOUNT = 30000 |
변수 | 카멜케이스, 명사, 복수형 s | category , categories |
함수 | 카멜케이스, 동사+명사 | getValue fetchUsers , navigateToNextPage |
클래스 | 파스칼 케이스 | ㅤ |
타입 | 파스칼 케이스 | ㅤ |
2. 브랜치 네이밍 미정
JIRA이슈-타입-기능이름(kebab-case) 으로 작성
ex) DG2-13-fix-login-page-route
ex) DG2-13-refactor-login-page-auth
ex) DG2-13-feature-login-page-auth
3. 파일 네이밍
export default | 파스칼 케이스 |
other | 카멜 케이스 |
hooks | use prefix (use를 맨앞에 씁니다.) |
▶️ Folder Structure 보류
주제 정하고 천천히~
▶️ develop merge 방식
PR올렸을 때 2명 이상 리뷰 후 approve해야 merge 가능합니다.
+ 리뷰 후 PR 다시 올렸을 때 approve 초기화 합니다.
▶️ 코드 리뷰 방식
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
는 프로젝트 설정 변경 시 사용
- 커밋 메세지는 JIRA 이슈의 키값을 포함한다
- 작성 예시 :
git commit -m 'DY2-5 feat: 로그인 버튼 추가"
✨Style Rules 미정
ESLint 미정
Prettier
TS Config
👩💻 Branch Rules 미정
github flow 전략을 사용한다
- 새로운 브랜치는 항상 main브랜치에서 만든다
- 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성하는 것으로 시작한다
- 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성한다
- 브랜치를 머지하기 위해서는 모든 팀원의 리뷰를 받아야 한다
- 브랜치를 성공적으로 머지했으면 해당 브랜치는 삭제한다
브랜치 규칙
✅ 작업 진행 순서
깃허브 이슈 생성
- 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: 배포용
- 작업은 각자 브랜치 파서 작업합니다.