Team Rules

생활 및 의사소통 규칙

• 매일 10시 디스코드 채널에 모여 하루 일과 시작
• 출근 및 팀 프로젝트 시간 10 - 23
• 10시 30분 회의 진행.
• 점시시간 13 - 14 // 저녁시간 17 - 19
• 23시 코드 리뷰 및 Dev-Log, Error Handling 작성
• 2:2 의견이 나눠질 시, 사다리타기 결과에 복종하기
• 주말:13:00 ~ 22:00
• 회의 중 의견 차이로 좋지 못한 분위기가 조성될 경우, 갈등 방지를 위해 모든 채팅어 끝에 '용'어체와 ❤️를 붙여 대화한다. ex) 용❤️, 죄송해용❤️
• 프로젝트 팀 운영에 있어 건의 사항은 자유롭고 적극적으로 제안한다.
• 자기실수 인정하고 사과하기

멤버별 Not To Do 다짐

• 김제완 : 회의하다가 "어?!"를 하지 않겠습니다.
• 이상석 : 프로젝트 기간 동안 새벽에 해외 축구 경기를 보지 않겠습니다.
• 정선우 : 무엇이든 Delete를 누르지 않겠습니다.
• 이승섭 : 팀원의 눈치를 보지 않겠습니다.

브랜치 이름 형식

종류	브랜치 역활
main	가장 최신의 배포된 버전, 출시될 수 있는 브랜치
dev	릴리즈 계획에 따라서 Github에서 기본 브랜치로 지정
feature	기능을 개발하는 브랜치
hotfix	출시 버전에서 발생한 버그를 수정 하는 브랜치

Commit Message Rule

• Title : #issue number/(client) or (server)/이슈명/commit 제목
  ex : Client Feat

• FIX (고친부분) 가장 자주 사용되는 커밋 로그 중 하나로 ‘Fix’가 있습니다. 보통 올바르지 않은 동작을 고친 경우에 사용합니다.

• ADD(추가 한 부분) 코드나 테스트, 예제, 문서 등의 추가가 있을 때 사용합니다

• REMOVE(삭제 한 부분)

• REFACTOR 전면 수정이 있을 때 사용합니다.

• SIMPLIFY 복잡한 코드를 단순화 할 때 사용합니다. Refactor의 성격이 강하나 이보다는 약한 수정의 경우 이용하면 좋습니다.

PR 규칙

• PR 제목 : feature/(c,s,d) - 기능명

Merge 규칙

• merge 전 꼭 전체 팀원에게 알린 후 merge 한다.
• 회의 때 리뷰 후 같이 Merge 한다.

변수 규칙

•  Camel Case (ex : backgroundColor)

파일, 생성자 이름

• Pascal Case (ex : BackgroundColor)

NODE, NPM 버전 토일

• node : v16.13.2
• npm : v8.3.1

Prettier Rule 설정

• Prettier 기본 설정
• Tab Width : 2
• Auto-Semicolon : Yes