githubRule

커밋 메시지 규칙

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

• 큰 틀은 git commitizen 을 따른다

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

Lint 규칙

브랜치 이름 형식

종류	사용패턴	특징
master	master	프로덕션 스냅샷 가장 최신의 배포된 버전
dev	dev	릴리즈 계획에 따라서 Github에서 기본 브랜치로 지정
feature	feature/컴포넌트명 또는 기능명 feature/name	dev에 병합
layout	layout/컴포넌트명 layout/name	dev에 병합
fix	fix/컴포넌트명 또는 기능명 fix/name	dev에 병합
hotfix	hotfix hotfix/	마스터에 병합

PR형식

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

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

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

• PR 제목

edit: readme

• PR 본문

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

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

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

에러 핸들링 형식

> 해결된 에러라면 라벨에 'Complete' 를 달아주세요.
> 미해결된 에러라면 라벨을 'In progress' 로 변경해주세요.

### 어떤 에러인가요?
- 

### 에러 메시지

$ 터미널의 에러 코드를 여기 넣어주세요.

### 에러 핸들링 방법

- 핸들링 방법에 대해서 간단하게 기록해보세요.

// 코드가 들어가도 좋아요!

### 에러 핸들링을 위해 참고한 레퍼런스 링크
[링크]()