Team Rule

커밋 메시지 규칙

커밋 메시지는 제목과 본문으로 나누어 집니다. 한 줄만 작성해도 설명이 충분하다면 제목만으로도 괜찮습니다. 하지만 어떤 변경 사항이 있는지 맥락과 설명이 필요하다면 본문을 작성할 수 있습니다. 다음은 제목과 본문을 작성하는 규칙입니다.

타입 첫글자를 대문자로 적어주세요.
타입은 명령어로 작성합니다.
제목과 본문을 한 줄 띄워 분리해 주세요.
제목은 50자 이내로 적어주세요.
제목은 명사형으로 작성해주세요.
제목 끝에 . 는 금지합니다.
본문은 50자마다 줄을 바꿔주세요.
본문은 어떻게 변경했는지 보다 무엇을 변경했는지, 왜 변경했는지 에 맞추어 작성하세요.

예시

$ <type>: <subject> -- 헤더
<BLANK LINE> -- 빈 줄
<body> -- 본문 
<BLANK LINE> -- 빈 줄 
<footer> -- 바닥 글

//type 예시
Feat: 새로운 기능을 추가할 경우 
Fix: 버그를 고친 경우 
Design: CSS 등 사용자 UI 디자인 변경 
!BREAKING CHANGE: 커다란 API 변경의 경우 
!HOTFIX: 급하게 치명적인 버그를 고쳐야하는 경우 
Style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우 
Refactor: 프로덕션 코드 리팩토링 
Comment: 필요한 주석 추가 및 변경 
Docs: 문서를 수정한 경우 
Test: 테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X) 
Chore: 빌드 태스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X) 
Rename: 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우 
Remove: 파일을 삭제하는 작업만 수행한 경우

Feat: 관심지역 알림 ON/OFF 기능 추가(#123)

시군구의 알림을 각각 ON/OFF 할 수 있도록 기능을 추가함

opnion0055: 구분 코드 해결: #123

Lint 규칙

semistandard 를 따릅니다. 주요규칙
space는 두 칸, 탭 사용 x
오직 single quote만 사용, 템플릿 리터럴은 표현식 사용할때만 사용하세요.
var 는 사용하지 않습니다.
키워드 다음엔 스페이스 하나를 띄워주세요.
참고링크(https://standardjs.com/rules.html)

브랜치 이름 형식

종류	사용패턴	특징
main	main	프로덕션 스냅샷 가장 최신의 배포된 버전
dev	dev	릴리즈 계획에 따라서 Github에서 기본 브랜치로 지정
feature	feature/이름 feature/branch-name	dev에 병합
hotfix	hotfix/이슈번호 hotfix/#911	메인에 병합

PR형식

코드 컨벤션을 잘 지켜주세요. 컨벤션 오류로 인한 불필요한 코멘트는 시간 낭비이기 때문에 지양하는 것이 좋습니다.
리뷰 가이드라인을 잘 작성해 주세요. 모든 코드 변경사항에는 의도가 필요합니다. 의도치 않게 변경된 부분이 있다면 되돌려 놓아야 하고, 줄바꿈과 같이 아주 단순한 변경사항이라도 그 부분을 리뷰어가 볼 필요가 없다면 “Just line change” 와 같은 코멘트를 달아 명시하여 리뷰 시간을 줄여줄 수 있을 것입니다. 또는 사용된 라이브러리 업데이트가 포함되었다면 해당 라이브러리의 릴리즈 노트 링크나 스크린샷을 첨부하는 것도 좋은 방법입니다.
작업중, 리뷰 가능 여부를 잘 명시해 주세요. 아직 코드를 작성 중일 때에는 [WiP] (Work in Progress) 를 타이틀 앞에 추가하고, 만약 작업이 끝났으면 이를 제거하고 review-needed 태그를 설정할 수 있습니다. 한 번 작업을 마쳤다고 끝난 것이 아니기 때문에 리뷰를 반영하는 중에도 이 과정을 반복하여 명시해 주세요.
PR 제목

[Client] / #88 / edit: readme

PR 본문

### PR 타입(하나 이상의 PR 타입을 선택해주세요)
-[] 기능 추가
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트

### 반영 브랜치
ex) feature/login -> dev

### 변경 사항
ex) 로그인 시, 구글 소셜 로그인 기능을 추가했습니다.

Issue 형식

Issue 제목

[title] / body

### Issue 타입(하나 이상의 Issue 타입을 선택해주세요)
-[] 기능 추가
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트

### 상세 내용
ex) Github 소셜 로그인 기능이 필요합니다.

### 예상 소요 시간
-[] `0.5h`
-[] `1h`
-[] `1.5h`
-[] `2h`
-[] `2.5h`
-[] `3h`

### 라벨
- 예상 소요 시간: `E: 1h`
- 그룹: `client`, `server`
- 긴급도: `High`, `Middle`, `Low`

변수 이름 - Camel-case

clientLogin

파일 & 생성자 이름 - Pascal-case

ClientSide

node & npm 버전 통일

node: v14.17.6
npm: v6.14.15

프로젝트 진행 규칙

팀원들간 존댓말을 사용하며, 상호 존중하는 마인드를 가지고 커뮤니케이션에 최선을 다한다.
의견이 나눠질 경우 다수결로 결정하며, 2:2로 나뉜 경우 아래의 규칙대로 의사결정한다.
- 충분한 의사소통을 통해 프로젝트에 더 적합한 의견으로 결정한다.
- 의견이 나뉘는 관련 파트의 담당 팀원의 의견으로 결정하되, 다른 팀원의 의견 중 반영할 수 있는 부분은 채택하는 방향으로 결정한다.
미리 약속한 회의 시간을 지키지 않을 경우, 지각비 10분 당 3000원을 팀원을 위해 기쁜 마음으로 기부한다. (줌 접속한 시간 기준)
정규회의 시간:
- 평일 오전 10:00~10:30(현재 진행상황, 오늘 처리할 task 등 브리핑)
- 평일 오후 17:00~18:00(코드리뷰 및 PR Merge, KPT 회고록 작성)

Team Rule - codestates/slow-postbox GitHub Wiki

Team Rule

커밋 메시지 규칙

Lint 규칙

브랜치 이름 형식

PR형식

Issue 형식

변수 이름 - Camel-case

파일 & 생성자 이름 - Pascal-case

node & npm 버전 통일

프로젝트 진행 규칙

⚠️ GitHub.com Fallback ⚠️

Team Rule - codestates/slow-postbox GitHub Wiki

Team Rule

커밋 메시지 규칙

Lint 규칙

브랜치 이름 형식

PR형식

Issue 형식

변수 이름 - Camel-case

파일 & 생성자 이름 - Pascal-case

node & npm 버전 통일

프로젝트 진행 규칙

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️