Team Rules

• 기획 회의는 전원 참석한다.
• 오후 2시 ~ 6시는 항시 연락 가능한 상태를 유지한다.
• 작업 시 기획 단계에 사용한 협업 툴을 적극 이용한다.

작업 중 기획 내용에 수정사항이 필요한 경우 팀원들과 토의한다. 주말은 자유롭게 작업한다.

👉 Commit Convention

Commit Header

• {commit header}: {commit title} (#{issue number})

Commit Body

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

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

• EX )

✨feat: Something (#1)
- body1
- body2

Commit header 종류	이모지	Commit 타입	설명
New Feature	✨:sparkles:	feat:	새로운 기능에 대한 커밋
Fix	:wrench::wrench:	fix:	기능 수정에 대한 커밋
Bug	🐞:bug:	bug:	버그 관련에 대한 커밋
Working In Process	⚙:gear:	wip:	진행 중인 사항에 대한 커밋
Refactor Code	:broom: :broom:	refactor:	코드 문법, 포맷(prettier) 등 리팩토링에 대한 커밋
Documentation	📚 :books:	docs:	도큐먼트 수정에 대한 커밋
Styling UI	🎨:art:	style:	HTML, CSS, 오타 수정에 대한 커밋
Package Manager	:key::key:	build:	패키지 매니저 설정할 경우
Test Code	:hourglass::hourglass:	test:	누락된 테스트 추가 또는 기존 테스트 수정
Revert	:leftwards_arrow_with_hook::leftwards_arrow_with_hook:	revert:	작업 되돌리기

👉 Branch convention

upstream

종류	사용패턴	특징
main	main	프로덕션 스냅샷가장 최신의 배포된 버전
dev-front	dev-front	프론트엔드 릴리즈 계획에 따라서 Github에서 기본 브랜치로 지정
dev-back	dev-back	백엔드 릴리즈 계획에 따라서 Github에서 기본 브랜치로 지정

origin (개인 포크 레포지토리)

종류	사용패턴	특징
feat	feat/이슈번호-테스크카드제목feat/1-Login_컴포넌트	dev에 병합띄어쓰기는 언더바_를 사용한다.
fix	fix/이슈번호fix/#911	메인에 병합

Lint convention

• semistandard 를 따릅니다.
• Prettier를 사용합니다.

주요 규칙

• space는 두 칸, 탭 사용 x
• 자바스크립트 코드는 single quote와 템플릿 리터럴을 사용하고, 렌더링 부분 HTML 코드는 double quote를 사용한다.
• line-wrapping은 80자를 기준으로 하는 것을 원칙으로 합니다.
• var 는 사용하지 않습니다.
• 키워드 다음엔 스페이스 하나를 띄워주세요.
• 더 많은 정보는 https://standardjs.com/rules.html 를 참고하세요.
  • 위 링크의 룰에서 오직 한 가지만 예외입니다. 세미 콜론 사용을 허용합니다.

PR type

• 코드 컨벤션을 잘 지켜주세요. 컨벤션 오류로 인한 불필요한 코멘트는 시간 낭비이기 때문에 지양하는 것이 좋습니다.

• 리뷰 가이드라인을 잘 작성해 주세요. 모든 코드 변경사항에는 의도가 필요합니다. 의도치 않게 변경된 부분이 있다면 되돌려 놓아야 하고, 줄바꿈과 같이 아주 단순한 변경사항이라도 그 부분을 리뷰어가 볼 필요가 없다면 “Just line change” 와 같은 코멘트를 달아 명시하여 리뷰 시간을 줄여줄 수 있을 것입니다. 또는 사용된 라이브러리 업데이트가 포함되었다면 해당 라이브러리의 릴리즈 노트 링크나 스크린샷을 첨부하는 것도 좋은 방법입니다.

• 작업중, 리뷰 가능 여부를 잘 명시해 주세요. 아직 코드를 작성 중일 때에는 [WiP] (Work in Progress) 를 타이틀 앞에 추가하고, 만약 작업이 끝났으면 이를 제거하고 review-needed 태그를 설정할 수 있습니다. 한 번 작업을 마쳤다고 끝난 것이 아니기 때문에 리뷰를 반영하는 중에도 이 과정을 반복하여 명시해 주세요.

• PR 제목

Feat/이슈번호 카드제목

• PR 본문

### PR 타입
- [] 기능 추가
- [] 기능 삭제
- [] 버그 수정
- [] 의존성, 환경 변수, 빌드 관련 코드 업데이트

### 반영 브랜치
feat/login -> dev-front
feat/login -> dev-back

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

How to issue

• Issue 제목

[title] / body

• Issue 본문

### Issue 타입
-[] 기능 추가
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트

### 상세 내용
- [ ] Github 소셜 로그인 기능
- [ ] 블라블라

### Lables
- 메인 커밋
- 작업 분야(front or back)
- 예상시간

---

• 요청 Issue 제목

📣[요청] 로그인 쿠키 문제

• 요청 Issue 본문

### 상세 내용
로그인 쿠키가 받아 와지질 않습니다.

[img]사진 첨부(Optional)

### Lables
- request
- 우선순위

Name convention

변수 이름 - Camel-case

ex) clientLogin

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

ex) ClientSide

상수 이름 Snake-case

ex) SNAKE_CASE

Stack version

Stack	Version
node	16.13.1 LTS
npm	8.3
express	4.17.1
mysql2	2.3.3
sequelize	6.12.0-beta.3
sequelize-auto	0.8.8
cookie-parser	1.4.4
cors	2.8.5
dotenv	10.0.0
jsonwebtoken	8.5.1
sequelize-cli	6.3.0