읽으면서 댓글로 자유롭게 의견나누고, 수정하는 방향으로 갑시다 : )
Git
- 브랜치 전략
git-flow - main - develop - fork한 레포의 feature
- 원본레포 fork(upstream) → 본인레포(origin) : 작업 후 pr → merge
- rebase로 합치기
- feat → dev (dev merge)
- 브랜치 네이밍
- 왜 함?? ← pr에 자세히 적으면 되지않을까?
- 이슈번호는 붙이지 말자
- Git 메세지
- 한글로 작성 (원하는 접두사가 없을 때, 2개 이상일 때..등 어떻게 대응)
- 접두사 ← 접두사 분류를 디테일하게 && 브랜치 네이밍 재사용
- pr, issue template
- 코드리뷰
- 승인 1명 이상 후 머지 → 깃허브 설정세팅
- pN 규칙 적용
- 그냥 궁금한 거면 ask, 진짜 궁금하면 just ask
코딩
- 폴더구조
- 타입관리
- 코딩 컨벤션
- 컴포넌트
- 로컬 환경
- eslint
- prettier
{ "jsxSingleQuote": true, "bracketSameLine": true, "singleQuote": true, "printWidth": 90, "tabWidth": 2, "useTabs": false, "semi": true, "quoteProps": "as-needed", "trailingComma": "es5", "arrowParens": "always", "endOfLine": "lf", "bracketSpacing": true, "requirePragma": false, "insertPragma": false, "proseWrap": "preserve" }
- git 관련
- husky: prettier —write, eslint —fix ⇒ pre-commit, pre-push 필터링
- lint-staged
- stage-area 안먹는 husky 를 도와줌