코드 네이밍
- 약어 없이 적절한! 풀네임(데일리스크럼 때 코드보면서 수정)
- 변수 : 카멜케이스
- 폴더 : 캐밥케이스
- 파일 : 파스칼케이스
- 커스텀 훅 : 카멜케이스
디렉토리 패턴
- src
- assets: 이미지, 아이콘, 폰트 관리
- pages: 라우팅에 사용되는 페이지
- [페이지 폴더]
- components: 페이지에서 사용되는 컴포넌트
- [각 컴포넌트 폴더]
- index.tsx: 컴포넌트 export
- constants
- index.ts: 현재 페이지에서만 사용되는 상수 관리
- types
- type.d.ts: 공통으로 사용되는 타입, 인터페이스 관리 (그 외는 각 컴포넌트에서 관리)
- hooks: 커스텀 훅 관리
- stores: 상태 관리
- apis: API 관리
- components: 공통, 재사용 컴포넌트
- utils: 공통 함수 관리
Git Convention 통일
- init: 프로젝트 생성 및 초기 설정
- feat: 새로운 기능 추가
- modify: 기존 기능 수정
- fix: 버그, 오류 수정
- docs : 문서(주석) 작성, 수정
- refactor : 기능의 변화가 아닌 코드 리팩터링 ex) 변수 이름 변경, 최적화, 가독성 개선, 중복 최소화, 컴포넌트 분리 등
- style : 디자인(css, 레이아웃)추가, 변경
- !hotfix: 급하게 치명적인 버그를 고쳐야하는 경우
- test: 테스트 코드 추가, 수정
- build: 빌드 관련 추가, 수정
- rename: 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
- remove: 파일을 삭제하는 작업만 수행한 경우
- chore: 패키지 매니저 업데이트 ex) .gitignore, package.json 관련
- release : 버전 릴리즈
- comment : 주석 추가 및 수정
개발 룰
코드 컨벤션
코드 네이밍
정하기 애매하다면 데일리 스크럼, 슬랙으로 논의
- 약어 없이 적절한! 풀네임 사용하는 것으로 원칙
- 변수 : 카멜케이스
- 폴더 : 캐밥케이스
- 파일 : 파스칼케이스
- import 순서
- import * from ‘react’
- 라이브러리
- 컴포넌트
- 커스텀 훅
- 경로 별칭
- ‘@’
함수 네이밍
동사 + 명사: clickButton
이벤트 핸들러 + props로 함수 넘길 때
handle + 명사 + 동사 : handleButtonClick
on + Event행위 + 명사(주최 ex) button ) : onClickYellowButton, onFocusRedButton
프로젝트 컨벤션
이슈, pr 규칙
- 태그 달기
- 템플릿
- 이슈
## 기능 요약 > 추가하거나 개선하려는 기능에 대해 간결하게 설명해 주세요. ## 상세 작업 내용 - [ ] TODO 1 - [ ] TODO 2 - [ ] TODO 3 ## 추가 정보 (선택) > 이 기능과 관련된 추가적인 정보나 참고할 문서, 디자인 파일 등이 있다면 링크를 포함해 주세요.
## 관련 이슈 > 이슈 링크: #이슈번호, #이슈번호 ## 작업 내용 > 해당 PR에서 작업한 내용을 간략히 설명해 주세요. (이미지 첨부 가능) > 코드가 아닌 기능 단위로 설명을 작성하며, 기능이 여러 개인 경우 각각을 잘 구분하여 설명해 주세요. <br /> ## 특이 사항 > 프로젝트 실행에 영향을 미치는 중요한 변경사항이나 주의사항 등을 기술해 주세요. <br /> ## 리뷰 요구사항 (선택) > 리뷰 중점 사항: 리뷰어가 특히 집중해서 봐야 할 부분이 있나요? > 추가 검토 사항: 코드, 디자인, 구현 방식 등에 대한 추가적인 검토가 필요한 사항이 있나요? > 논의가 필요한 부분: 코드 리뷰 중 논의가 필요해 보이는 부분은 무엇인가요?
- close 할 때, 어느 pr#으로 해결했는지 링크걸기
- ## 해결
> #14 (PR Num)
Branch Rule
1. Require a pull request before merging
merge를 위해서는 pull request를 강제하는 옵션입니다. 해당 브랜치에 수정 내역을 반영하려면 일반적인 푸시가 아닌 반드시 PR을 올리는 작업이 선행되어야 합니다. 보호가 필요한 브랜치라면 대부분의 경우 사용하게 될 속성입니다.
세부적으로 코드 리뷰가 필요한지, 필요하다면 최소 몇 명의 리뷰가 있어야 하는지, 리뷰 작업 중 변동 내역이 있다면 기존의 승인을 취소할지에 대한 여부 등을 정할 수 있습니다.
→ 2명 ⭕️
2. Require status checks to pass before merging
merge 전에 상태 체크를 먼저 진행합니다. 테스트 코드등을 미리 돌려 문자 그대로 PR의 상태를 확인할 수 있습니다. 상태 체크의 경우 Github Action을 통해서 가능합니다. Github Action Workflow를 구성하는 자세한 방법은 PR시 미리보기 구현하기 (Github Actions) 포스팅을 참고해주세요.
→ 보류 ⛔️
3. Require conversation resolution before merging
merge 전에 PR에 남겨진 코멘트(conversation)를 모두 확인해야 합니다. 남겨진 모든 코멘트에 답을 달아주어야 머지가 되는 옵션으로 코드 리뷰를 꼼꼼하게 진행할때 사용하기 좋습니다.
→ OK ⭕️
4. Require signed commits
서명된 커밋만 푸시될 수 있도록 하는 규칙입니다. verify 마크가 찍힌 커밋들만 푸시가 가능한데, 믿을 수 있는 출처에서부터 생산된 커밋이라고 생각하시면 될 것 같습니다. 서명된 커밋에 대한 정보는 이곳에서 확인하실 수 있습니다.
→ NO ❌
5. Require linear history
선형적인 히스토리 관리를 위해 일반적인 머지를 막고, 스쿼시나 리베이스를 통한 머지만 하도록 허용합니다. 여러 갈래로 뻗어진 브랜치는 문제가 발생했을때 히스토리를 추적하고 이전으로 되돌리기가 어렵기 때문에, 브랜치 모양을 단순하게 관리하고 싶을때 사용하면 좋은 옵션입니다.
→ NO ❌
6. Require deployments to succeed before merging
머지되기 전 반드시 배포에 성공해야만 머지가 가능하도록 하는 옵션입니다. 해당 레포지토리에 세팅 된 환경 중 배포 성공을 확인할 대상을 선택할 수 있습니다.
레포지토리에 세팅된 environment를 자동으로 가져옵니다.
→ 1차 배포 후 설정 ⭕️
7. Lock branch
누구도 브랜치에 푸시할 수 없도록 read-only로 만듭니다.
→ NO ❌
8. Do not allow bypassing the above settings
관리자 권한을 가진 유저들도 해당 설정을 지키지 않으면 머지할 수 없도록 막습니다. 이 옵션을 체크하지 않으면 관리자 권한이 있는 유저는 경고를 무시하고 머지할 수 있습니다.
→ OK ⭕️