[SR] 팀 규칙 / 팀룰

### Dev-Log 개발일지
* 하루를 마무리하기 전에 간단하게 라도 Dev-Log을 작성하고 취침합니다.

### Discussions
* 아이디어 제안이나 상의할 것이 생각났다면 디스커션 메뉴에 자유롭게 기입하고, 댓글로 수시로 의견 나눕니다.

### 컴포넌트 규칙
1. 파스칼 표기법을 사용합니다. (ex. WeAreTheOne) - 앞글자 대문자 표기!
2. 기본적으로 함수 컴포넌트로 제작합니다. (React Hooks 사용)
3. 타입스크립트 적용에 따라 모든 컴포넌트 파일의 확장자는 ts 또는 tsx 사용 (jsx 문법 포함 시만 tsx)

### 변수 & state 규칙
1. 카멜 표기법을 사용합니다. (ex. weAreTheOne) - 앞글자는 소문자, 뒷음절부터는 앞글자 대문자 표기!
2. 서버 controller에서 응답을 줄 때 변수도 카멜 표기법을 지킵니다.

### className 규칙
1. 파스칼 표기법을 사용하되 각 단어 사이에 _ 로 구분합니다.
ex) Main_Btn

### 커밋 메세지 작성 규칙

1. 제목 작성 요령
* 깃모지 활용: https://treasurebear.tistory.com/70
* 클라이언트: [깃모지][페이지명][기능명] 수정한 내용을 문장으로 작성합니다. ex) [✨][MyPage][EditFarmerInfo] 사용자 정보 수정 기능 구현
* 서버: [깃모지] API 엔드포인트 형식으로 작성합니다. ex) [✨] /users/signup 엔드포인트 구현
* 페이지명 - 화면에 표시되는 페이지 컴포넌트의 이름을 작성합니다.
* 기능명 - 페이지 내에서 작동하는 기능 컴포넌트의 이름을 작성합니다. 컴포넌트가 아닐 경우 일반적인 기능명으로 대체.
* 설명 - 한눈에 내용을 알아보기 용이한 개조식 문장을 사용합니다.
ex) 합니다. 입니다. => 함. 임

2. 내용 작성 요령
* 수정하거나 추가한 파일 이름을 작성하고 수정한 내용을 기입합니다.
ex) app.js → root 컴포넌트 호출
* 다른 사람이 봤을 때 어떤 작업을 한건지 충분히 이해할 수 있도록 합니다.
* 사소한 것을 수정했어도 기입해야 합니다.
ex) 변수명 변경

### PR 메시지 작성 규칙
1. 커밋메시지와 동일하게 작성하되, 커밋메시지에서 미처 생각나지 않은 내용이 있으면 추가할 것.

### Prettier Rule 설정
* Tab Width : 2
* Auto-Semicolon : Yes
* Tslint 설정하여 커밋 시 console.log 있으면 오류 띄우기

### 모든 commit은 Issue/Task 카드를 기준으로 행해진다!
* Task 카드에 없는 내용을 코딩중이면 반드시 새로운 Task 카드를 생성하거나 기존 Task 카드를 수정해야 한다.

### 브랜치(Branch) 규칙
0. 브랜치 이름의 종류는 총 4가지만 사용한다. master, dev, feature, bugfix
1. Issue/Task Card 생성 시 자동으로 만들어지는 번호(#)와 feature#를 일치시켜야 한다.
ex) Task Card #13 => feature13
2. 번호가 한 자리수이어도 feature5보다는 feature05로 기입해 준다.
3. 한 번 사용한 feature branch는 더 이상 push하지 않는다. 한 번 쓴 총알은 사용할 수 없다고 생각하자.
4. 버그수정 시 bugfix# 와 같은 형식을 따르자.
ex) 이미 Merge가 끝난 Task15/feature15 기능에서 버그가 발견되서 수정 작업을 했다면, bugfix15 브랜치명을 사용.
5. 예외적으로 css 스타일을 입히는 Task의 경우 위와 같은 브랜치 Numbering Rule을 적용하지 않는다.
6. dev branch는 늘 최신 상태로 유지한다고 생각하자.
7. master branch에서는 배포 준비를 위해 console.log나 사용하지 않은 변수 등 불필요한 코드들을 모두 제거한 상태여야 한다.
8. 사소한 수정 사항은 굳이 새로운 Task 카드 새로 만들지 않고 reopen 하여 기록 남기기.