[Profile] team convention

• 원활한 협업, 소통 그리고 유지보수를 위해 team convention 중요시 생각합니다.
• 따라서 회의를 통해 convention을 만들고 문서화합니다.
• code convention의 경우 Linter, Formatter, Husky를 통해 걸러냅니다.

예시

1. .eslintrc.json

{
  "plugins": ["@typescript-eslint"],
  "extends": [
    "next/core-web-vitals", // next 기본 rule set, https://nextjs.org/docs/basic-features/eslint#core-web-vitals
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier" // prettier를 가장 마지막에 추가
  ]
}

2. .prettierrc.json

{
  "semi": false,
  "trailingComma": "none", // 맨끝 콤마
  "singleQuote": true,
  "tabWidth": 2,
  "useTabs": false,
  "printWidth": 80,
  "bracketSpacing": true,
  "endOfLine": "lf"
}

3. 브랜치 전략

• git flow

브랜치 종류

(feature, fix, refactor…) + develop + main

1. pr 성격에 따라 feat,fix.. + /컴포넌트명 또는 기능명 + (- 상세) 브랜치 만들기
   • 예시
     • feature/UserPage
     • refactor/UserPage-followbutton // 자율적
     • fix/Input-formatBug
     • feature/getLevel : 유저의 레벨 구하는 함수 구현
2. 브랜치 작업 끝나면 develop에 pr 후 squash merge
3. develop 실행 가능한 단위로 release에 pr 후 squash merge
4. release에서 자동배포, 테스트 CI/CD
5. main에서 실제 배포(CD)

4. 커밋 메세지 규칙

소문자 tag: 한글로 된 상세 설명

feat: 사용자 페이지 유효성 검사 추가

• 태그 예시 여시서 다른 건 그대로 아래만 예외적으로 의미변경
  • chore: 주석제거 등 별로 중요하지 않는 잡다한 코드 수정일 때
  • style: css, scss, emotion등 스타일관련 작업시
  • desigin 사용하지 않음 대신 style로 통일

그 외 컨벤션 보기