‘GitHub Projects를 쓸 것인가?’

• 장점: Issue 생성 및 관리, task별 진척도 관리 용이
• 단점: 약간의 learning curve 존재 ← 이건 예시 한 번 보여드리고, 할 만 하다 싶으면 채택해도 될 것 같아요
• 안쓰기로

branch 규칙

• branch 전략
  • feat : 기능 단위 개발을 위한 branch
  • fix : 버그 수정
• branch 이름은 다음과 같은 방식으로 작성한다:
  • feat/some-feature
  • fix/some-error

commit 규칙

• 영어와 한글 혼용 기재
• 형식: <타입>: <변경 요약> (e.g. feat: 내용)

  • 예시:

    # 제목은 최대 50글자까지 아래에 작성: ex) Feat: Add Key mapping  
    # 본문은 아래에 작성  
    # --- COMMIT END ---  
    #   <타입> 리스트  
    #   feat        : 기능 (새로운 기능)  
    #   fix         : 버그 (버그 수정)  
    #   refactor    : 리팩토링  
    #   design      : CSS 등 사용자 UI 디자인 변경  
    #   comment     : 필요한 주석 추가 및 변경  
    #   style       : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)  
    #   docs        : 문서 수정 (문서 추가, 수정, 삭제, README)  
    #   test        : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)  
    #   chore       : 기타 변경사항 (빌드 스크립트 수정, assets, 라이브러리 추가, 패키지 매니저 등)  
    #   init        : 초기 생성  
    #   rename      : 파일 혹은 폴더명을 수정하거나 옮기는 작업만 한 경우  
    #   remove      : 파일을 삭제하는 작업만 수행한 경우  
    # ------------------  
    #   제목 첫 글자를 대문자로  
    #   제목은 명령문으로  
    #   제목 끝에 마침표(.) 금지  
    #   제목과 본문을 한 줄 띄워 분리하기  
    #   본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.  
    #   본문에 여러줄의 메시지를 작성할 땐 "-"로 구분  
    # ------------------  
    

feat: 메인 페이지 개발

issue 규칙

• 한글로 작성 (제목과 내용)
• 형식: [<타입>]: <요약> (타입의 경우 첫 글자만 대문자로)
  • 예시: [Feat]: 어떤 기능
• issue template을 사용
• github project와 연동한다.

pull request 규칙

코드 리뷰

한 명이 eslint 문제 없는거 체크하고 검토 완료하기

• 영어와 한글 혼용 기재

• 형식: <타입>: <요약>

  • 예시: feat: 무슨무슨 기능

  ## 🔗 관련 이슈
  
  <!-- 연관된 이슈 번호를 작성해주세요. -->
  
  - #이슈번호
  
  ## 📌 PR 내용
  
  <!-- PR 내용을 설명해주세요. -->
  
  -
  
  ## 🗣️ 팀원에게 공유할 내용
  
  <!-- 팀원들이 알아야 할 내용이나 논의해야 할 부분이 있다면 작성해주세요. -->
  <!-- 리뷰어가 중점적으로 봐줬으면 하는 부분이 있으면 작성해주세요. -->
  
  -
  
  ## eslint 체크 이미지 업로드