Skip to content

협업 규칙 (Collaboration Rules)

JUNSANG YOO edited this page Jul 17, 2022 · 13 revisions

협업을 진행하면서 서로 지켜야할 규칙들을 기록합니다.

  • 개발 기간

    22.07.01 ~

  • 역할 분담

    • 유준상 : splash, 로그인, 회원가입, 프로필 수정, 404 Not Found 페이지
    • 류재준 : 피드, 검색, 하단 탭 메뉴, 좋아요, 모달 버튼
    • 오한솔 : 사용자 프로필 페이지, 팔로워, 팔로잉 목록, 상품 등록
    • 장소연 : 게시글 댓글, 작성 페이지, 채팅 목록, 채팅방
  • 코드 컨벤션

    • HTML

    • CSS

  • ESLint

{
    // env: 어떤 환경에서 스크립트를 실행할 것인지 설정
    "env": {
        "browser": true,
        "es2021": true,
        "node": true
    },
    "settings": {
        "react": {
            "version": "detect"
        }
    },
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended"
    ],
    "parserOptions": {
        // ECMAScript 규격의 JSX 사용 여부: true
        "ecmaFeatures": {
            "jsx": true
        },
        // 사용할 ECMAScript 버전을 설정
        "ecmaVersion": "latest",
        // parser의 export 형태를 설정, react는 module 기반의 import, export 사용
        "sourceType": "module"
    },
    "plugins": [
        "react"
    ],
    "rules": {
        // 들여쓰기 2칸만 허용
        "indent": ["error", 2],
        // var 키워드 사용 불가능
        "no-var": "error",
        // asynn 함수 내부에 await 키워드가 없으면 오류 발생
        "require-await": "error",
        // ==, != 대신에 ===, !== 사용
        "eqeqeq": "error"
    }
}
  • Prettier

{
    "tabWidth": 2,
    "singleQuote": true,
    "semi": true,
    "printWidth": 80,
    "useTabs": false,
    "bracketSpacing": true
}
  • 커밋 컨벤션

    • 커밋 단위는 UI 구현 시에는 컴포넌트 단위, 기능 구현 시에는 구현 하나로 지정한다.
    • 커밋 메세지는 #<이슈 번호> - <키워드>: 상세 설명 으로 통일한다.
    • 위에서 설명한 키워드의 종류는 다음과 같다.
      • Feat: 새로운 기능을 추가할 경우
      • Fix: 버그를 고친 경우
      • Design: CSS등 사용자 UI 디자인 변경
      • !BREAKING CHANGE: 커다란 API 변경의 경우
      • !HOTFIX: 급하게 치명적인 버그를 고쳐야하는 경우
      • Style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
      • Refactor: 프로덕션 코드 리팩토링
      • Comment: 필요한 주석 추가 및 변경
      • Docs: 문서를 수정한 경우
      • Test: 테스트 추가, 테스트 리팩토링
      • Chore: 빌드 태스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X)
      • Rename: 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
      • Remove: 파일을 삭제하는 작업만 수행한 경우

    참고: https://overcome-the-limits.tistory.com/entry/%ED%98%91%EC%97%85-%ED%98%91%EC%97%85%EC%9D%84-%EC%9C%84%ED%95%9C-%EA%B8%B0%EB%B3%B8%EC%A0%81%EC%9D%B8-git-%EC%BB%A4%EB%B0%8B%EC%BB%A8%EB%B2%A4%EC%85%98-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0

  • Branch 컨벤션

    • Git Flow에서 main, develop, feature branch만 활용한다.
    • feature branch명은 feature-이슈번호로 지정한다.
      ex) git commit -m "#14 - Feat: 로그인 기능 구현"
    • 각 Branch의 역할을 다음과 같다.
      1. main: 현재 서비스가 배포된 상태의 코드가 담긴 Branch
      2. develop: 다음에 배포할 버전의 서비스를 위한 코드가 담긴 Branch
      3. feature: 개별적으로 기능 및 UI를 구현할 때 생성하는 Branch
  • Github 컨벤션

    • 모든 개발을 시작할 때에는 Issue를 발행하여 팀원들과 공유한다.
    • Issue 제목은 <키워드>: 상세 설명 으로 통일한다.
    • Pull Request를 생성할 때 더 자세한 리뷰가 필요하면 help wanted 라벨을 남겨놓는다.
    • Pull Request는 최소 팀원 2명의 comment를 받고 merge 시킨다.
    • 본인의 Pull Request는 반드시 본인이 merge 시킨다.
  • 파일 디렉토리 디자인 컨벤션

    • node_modules

    • package.json

    • package-lock.json

    • .gitignore

    • public

      • index.html
      • data 폴더
    • src

      • App.js
      • index.js
      • assets 폴더: 이미지, svg 파일 등
      • components 폴더: 여러 페이지에서 재사용되는 컴포넌트들을 저장하는 폴더
      • pages 폴더: 해당 페이지를 구성하는 컴포넌트들을 저장하는 폴더