Team Rules

Ground Rule

• Done is better than perfect
• 휴가, 반가 사용시 1주일 전에는 슬랙에 공지합니다.
• 지각시 30분 전에는 알려주세요.
• 식사시간 11:30 ~ 12:50 입니다. 가급적 1시부터는 바로 시작할 수 있게 해주세요.
• 30분 ~ 1시간동안 동일한 문제 해결하지 못할경우, 다른 팀원들에게 바로 알려주고, 문제의 우선순위에 따라 페어프로그래밍을 할지 결정 합니다.
• 스프린트의 첫 날은 한 주의 작업 풀을 설정하고, 필요에 따라 기반 코드를 페어프로그래밍으로 작성후 개별 작업을 진행합니다.
• 기획 및 개발 산출물은 구글 드라이브 공유 폴더에 저장합니다.

Code review

• 모든 PR은 적어도 한명의 reviewer에 의해 리뷰되어져야합니다.
• 페어 코딩 및 2인 이상이 설계한경우 이미 리뷰된것으로 간주 할 수 있습니다.

Coding Convention

• js의 코딩 컨벤션은 eslint-config-naver 을 따릅니다.
• CSS 방식은 styled component 로 합니다.
• CSS 라이브러리sms material-ui 를 사용합니다.

개발 환경

• 개발에 사용할 IDE는 자유입니다.
• .vscode, .idea 같은 idea 설정파일은 깃 커밋에서 제외합니다.
• 페어 코딩시 vscode 권장합니다.

git 사용 규칙

• git 사용툴은 gitkraken을 사용합니다.
• github flow를 기본 전략을 따릅니다.
• 브렌치 병합은 rebase 방식을 권장합니다.
• 브렌치 명명 규칙은 git flow의 규칙을 따릅니다.
• PR을 하기전에 eslint를 사용하여 lint error가 없는지 확인합니다.

git Commit 규칙

• 첫줄은 커밋의 라벨, 제목 이슈넘버를 필수로 적습니다.

• 두번쨰 줄은 공백만 남깁니다.

• 세번쨰 줄부터 커밋에 관한 내용을 적습니다.

• 커밋 내용 형식은 markdown 형식을 권장합니다.

• 커밋된 코드는 prettier로 정리되어야합니다.

• git commit message의 라벨은 다음과 같습니다.

  • feat: 새로운 기능 추가
  • delete: 기능 삭제
  • fix: 버그 수정
  • docs: 문서 수정
  • lint: 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우
  • refactor: 코드 리펙토링
  • test: 테스트 코드, 리펙토링 테스트 코드 추가
  • chore: 빌드 업무 수정, 패키지 매니저 수정
  • typo: 오타수정
  • enhance: 간단한 개선사항을 기능에 추가

• 커밋 메세지 예시는 다음과 같습니다.

  fix: 모달 닫힘 버그 수정 #33
  
  # why
  왜 이커밋이 필요한지
  
  # how
  어떻게 구현 또는 문제를 해결했는지
  
  # warning
  요구조건은 만족하지만 잠재적으로 문제를 일으킬 수 있는 사항