Git Convention

Issue Convention

(동영 멘토님 템플릿)

## Feature Request

### Description
문제에 대한 간결하고 분명한 설명

### Possible Implementation

**Describe the solution you'd like**
A clear and concise description of what you want to happen

**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've already considered.

### Context

**Additional context**
Add any other context or screenshots about the feature request here.

Branch Convention

• 무조건 1이슈1브랜치(1PR)

• PR은 해당 이슈의 모든 구현사항이 해결되면 그 후 merge

• 기능 별로?

• 대문자

• #[IssueNumber]/[Main Label]/영어제목

#12/Feat/모달 창 구현
#23/Feat/로그인 페이지 구현
#100/Docs/문서 정리

Commit Convention

제목

• 제목은 명령조로 작성하여, 목적을 명확히 한다.

• 이모지 안 쓰고

• 시작은 대문자 (Feat, Fix, …)

• 슬래시(’/’)로 구분

본문

• 제목과 구분되기 위해 한칸을 띄워서 작성한다.

커밋 타입

• Feat : 기능 추가

• Delete : 기능 삭제

• Modify : 기능 수정

• Docs : 문서 수정 / 코드 수정 없음

• Style : css, 정렬

• Refactor : 코드 리팩토링

• Fix: 오타 수정

• Test : 테스트 코드와 관련된 모든 변경

• Chore
• 주석 변경, 세미콜론, 공백 등
• 빌드 업무 수정, 패키지 매니저 수정 외 및 위의 해당 되지 않는 모든 사항

예시

# 올바른 커밋 메세지

Feat: Product 컴포넌트에 authentication 기능 추가
		
- 세부 내용을 설명하는 항목입니다.
- 가급적이면 간결하게 작성합니다.

PR Convention

PR Template

제모옥은..이제..고추장...닭쪼림으로...하겠습니다..근데..이제..바질을..곁들인..

### Description
- 결과물(이미지 또는 움짤 참조할 것)
- 문제가 무엇인지에 대하여 분명하고 간결한 Description (이 PR을 통해 해결하는 문제)
- 문제를 해결하기 위해 도입한 개념, 방안

### Implementation
- 디렉토리, 파일 구조에 대한 설명
- 구현한 기능의 논리에 대한 설명
- 변경점에 대한 설명

### 중점적으로 봐줬으면 하는 부분
- 변경사항이 큰 경우 집중해야 할 부분
- 불안해서 봐주었으면 하는 부분 등

원칙

• 원격 저장소에 PR을 올리기 전에
• 컴파일 오류가 없음을 보장
• 최신 develop 브랜치의 소스 위에서 수정이 진행되었는지 점검. 그러지 않았다면 최신 develop 소스를 풀 받고, 컨플릭트가 났을 경우 해결해서 PR
• develop을 직접 수정하면 안 됩니다.  develop 브랜치 위에 커밋 X. 반드시 feature 또는 Issue 브랜치를 만들어 그 위에 작업해야합니다.
• 불필요한 주석과 console.log가 없는지 확인합니다.
• PR을 작성할 때는 커밋 내역을 내용으로 첨부하고, 이외에 팀원들에게 자신의 소스 수정에 대해 알릴 사항, 혹은 작업 내역을 보여줄 수 있는 이미지를 첨부합니다.

• 컨플릭트도 본인이 해결해서 컨플릭트를 리졸브하는 커밋을 하고 컴플릿합니다.

• 코드리뷰는 n시간 안에 작성합니다?

• 리뷰에 대한 응답은 n시간 안에 작성합니다?

MERGE

• 본인이 올린 PR은 본인이 MERGE. 이는 코드리뷰로 진행된 피드백을 확인하고, 반영할지 혹은 그렇지 않을지 본인이 선택할 수 있는 여지를 남기기 위해서입니다.

• 다른 4명의 팀원 중 2명 이상이 approve하였을 경우에만 merge합니다.

• 서브브랜치 1명

• 커멘트 리졸브

on Review

• 코드리뷰로 달린 모든 코멘트를 확인할 것

• active에서 resolved로 바꾸는 것도 PR을 올린 사람의 몫.

• 피드백을 수용한다면 수정 후 resolved로, 피드백을 수용하지 않는다면 추가 코멘트를 달고 closed.

Review Convention

원칙

• PR 내역에 대하여, ‘이 코드는 틀려먹었다’라는 마인드로 접근할 것. 컨트리뷰터와 리뷰어는 공동 책임자이다.

• 모든 CL(Change List)를 컴토할 것.

• 컨트리뷰터는 리뷰어에게 CL에 대한 정보를 충분하게 제공할 것.

Review Template…?

0. 총평?

- [ ] 1. 돌아 가는가
- [ ] 2. 컨벤션
- [ ] 3. 디렉토리
- [ ] 4. 컴포넌트 구조
- [ ] 5. 최적화 및 로직
- [ ] 6. 중복
- [ ] 7. UI

8. 기타

1. 돌아 가는가 : 물론 PR을 올리는 개발자는 돌아가지 않는 코드를 PR해서는 안 됩니다. 하지만 컴파일 오류가 날 수 있는 치명적이고 명백한 코드가 수정된 소스안에 남아 있다면 코멘트를 남깁시다.

2. 컨벤션 : 팀의 코드 컨벤션을 어기는 부분은 없는지 점검합니다. 변수명이나 함수명, 이벤트명등이 직관적으로 이해되지 않는다면 코멘트를 남깁니다.

3. 디렉토리 : 새로운 파일이 생성되었다면 생성된 파일이 적합하고 가시성있는 위치에 컨벤션을 준수하여 저장되어 있는지 확인합니다.

4. 컴포넌트 구조 : 컴포넌트의 네스팅 깊이가 너무 깊어 특정 코드에 접근하기 어렵거나 너무 얕아 코드의 재사용성이 떨어지고 특정 파일이 특히 길어진다던지 하는 컴포넌트 구조와 배치를 확인합니다. 수정된 컴포넌트의 구조가 확장에 용이한지 살핍니다.

5. 최적화 : 코드가 불필요한 http 요청을 굳이 하지는 않는지, 렌더링 과정에서의 부하나 불필요한 컴포넌트의 재랜더링이 이루어지고 있지는 않나 확인합니다.

6. 중복 : 컴포넌트들 사이에서 같은 로직과 코드를 하드코딩해서 사용하고 있지는 않나 확인합니다. 그런 로직이 있다면 util로 분리하는게 좋습니다.

7. UI : 코드를 보고 구현된 실제 뷰가 요구사항에 맞게 잘 렌더링 되지 않을 수도 있겠다는 우려가 생길 수 있습니다. 그런 경우 직접 브랜치를 내려받아 돌려보시고, 무슨 문제인지 눈으로 직접 보고 판단하는게 좋습니다. 귀찮은 일일지도 모르겠습니다만, 더 나은 팀을 위해서는 적극적으로 서로의 실수를 검증하는 깐깐한 자세가 필요하다고 생각합니다.

Comment Convention

• 단순히 대체 코드를 제시하거나 문제가 있다고 말하는 것이 아니라, 그 근거를 자세히 설명할 것.

• 코드 작성자와 리뷰어는 서로 코드를 이해하는 방향이 다를 것이다. 자신이 이해한 방향과 근거를 자세히 설명할 것.

• 버그, 논리 오류로 인한 Suggestion의 경우 문제 지점에 대해 설명할 것.

• 컨벤션이나 주관적인 영역의 경우 판단 및 논의의 기준이 될 수 있는 레퍼런스를 참조할 것.

Reference