PR 제목은 이슈와 같은 형태로 작성합니다.

**로그인, 회원가입 구현**

### 이슈 번호 <!-- 관련된 이슈의 번호를 # 뒤에 입력해주세요  -->

- close: #

### 특이 사항 <!-- PR을 볼 때 미리 알아야 하거나, 주의 깊게 봐야 하는 점을 알려주세요 -->

- 특이 사항 1
- 특이 사항 2

• 가이드를 따라 PR 합니다.
• 최대한 모든 팀원이 리뷰하고 merge 합니다.
• commit 컨벤션을 지킵니다.
• 원격저장소에 올리고 PR을 올리기 전에
  • 컴파일 오류가 없음을 보장
  • 최신 develop 브랜치의 소스 위에서 수정이 진행되었는지 점검. 그러지 않았다면 최신 develop 소스를 풀 받고, 컨플릭트가 났을 경우 해결해서 PR
  • develop을 직접 수정하면 안 됩니다. develop 브랜치 위에 커밋 X. 반드시 feature 브랜치를 만들어 그 위에 작업해야합니다.
  • 불필요한 주석과 console.log가 없는지 확인합니다.
  • PR을 작성할 때는 커밋 내역을 내용으로 첨부하고, 이외에 팀원들에게 자신의 소스 수정에 대해 알릴 사항, 혹은 작업 내역을 보여줄 수 있는 이미지를 첨부합니다.
• 충돌이 이루어날 경우 PR 올린사람이 해결
• 본인이 올린 PR은 본인이 머지합니다. 이는 코드리뷰로 진행된 피드백을 확인하고, 반영할지 혹은 그렇지 않을지 본인이 선택할 수 있는 여지를 남기기 위해서입니다.
  • develop에 merge할 때는 squash merge를 사용해주세요!
• 코드리뷰로 달린 코멘트들을 모두 확인하고 active에서 resolved로 바꾸는 것도 PR을 올린 사람 몫입니다. 피드백을 수용한다면 수정 후 resolved로, 피드백을 수용하지 않을 것이라면 추가 코멘트를 달고 closed로 옮겨주세요.
• 컨플릭트도 본인이 해결해서 컨플릭트를 리졸브하는 커밋을 하고 컴플릿합니다.

코드리뷰 체크리스트

1. 돌아 가는가 : 물론 PR을 올리는 개발자는 돌아가지 않는 코드를 PR해서는 안 됩니다. 하지만 컴파일 오류가 날 수 있는 치명적이고 명백한 코드가 수정된 소스안에 남아 있다면 코멘트를 남깁시다.
2. 컨벤션 : 팀의 코드 컨벤션을 어기는 부분은 없는지 점검합니다. 변수명이나 함수명, 이벤트명등이 직관적으로 이해되지 않는다면 코멘트를 남깁니다.
3. 디렉토리 : 새로운 파일이 생성되었다면 생성된 파일이 적합하고 가시성있는 위치에 컨벤션을 준수하여 저장되어 있는지 확인합니다.
4. 컴넌 구조 : 컴포넌트의 네스팅 깊이가 너무 깊어 특정 코드에 접근하기 어렵거나 너무 얕아 코드의 재사용성이 떨어지고 특정 파일이 특히 길어진다던지 하는 컴포넌트 구조와 배치를 확인합니다. 수정된 컴포넌트의 구조가 확장에 용이한지 살핍니다.
5. 최적화 : 코드가 불필요한 http 요청을 굳이 하지는 않는지, 렌더링 과정에서의 부하나 불필요한 컴포넌트의 재랜더링이 이루어지고 있지는 않나 확인합니다.
6. 중복 : 컴포넌트들 사이에서 같은 로직과 코드를 하드코딩해서 사용하고 있지는 않나 확인합니다. 그런 로직이 있다면 util로 분리하는게 좋습니다.
7. UI : 코드를 보고 구현된 실제 뷰가 요구사항에 맞게 잘 렌더링 되지 않을 수도 있겠다는 우려가 생길 수 있습니다. 그런 경우 직접 브랜치를 내려받아 돌려보시고, 무슨 문제인지 눈으로 직접 보고 판단하는게 좋습니다. 귀찮은 일일지도 모르겠습니다만, 더 나은 팀을 위해서는 적극적으로 서로의 실수를 검증하는 깐깐한 자세가 필요하다고 생각합니다.