깃 커밋 컨벤션?
- 개발자가 커밋에 대한 메시지를 작성할 때 따르는 일련의 규칙이다.
- 프로젝트 또는 조직 전체에서 더 많은 정보를 제공하고 읽기 쉽고 일관성 있게 만든다.
1
2
3
4
5
| <type>[optional scope]: <description>
[optional body]
[optional footer(s)]
|
풀 리퀘스트 컨벤션?
- 개발자가 Git과 같은 버전 제어 시스템에서 풀 요청을 만들고 제출할 때 따르는 규칙이다.
- 이러한 규칙은 풀 요청이 체계적이고 유익하며 검토하기 쉬운지 확인하는 것을 목표로 한다.
커밋
커밋 메시지 조약
1
2
3
4
| 커밋 제목: url이 /admin/default 일 때 사이드바 렌더링 X
type: feat
body: 프로젝트 리스트 페이지에서 사이드바 렌더링을 하지 않기 위해 템플릿에서 제일 홈 페이지인 admin/default 페이지에서 사이브바 렌더링을 url에 따라 결정하는 걸로 수정했습니다.
|
커밋 타입
| Feature | 새로운 기능을 추가할 경우 |
|---|
| Fix | 버그를 고친 경우 |
| Change | 기존 기능에 변경이 있는 경우 |
| Design | CSS 등 사용자 UI 디자인 변경 |
| !BREAKING CHANGE | 커다란 API 변경의 경우 |
| !HOTFIX | 급하게 치명적인 버그를 고쳐야하는 경우 |
| Style | 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우 |
| Refactor | 프로덕션 코드 리팩토링 |
| Comment | 필요한 주석 추가 및 변경 |
| Docs | 문서를 수정한 경우 |
| Test | 테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X) |
| Chore | 빌드 태스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X) |
| Rename | 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우 |
| Remove | 파일을 삭제하는 작업만 수행한 경우 |
풀 리퀘스트
풀 리퀘스트 순서
update from develop → resolve conflict → create pull request to develop
풀 리퀘스트 작성 템플릿
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| ## PR Checklist
아래 요구사항을 만족하는지 체크:
- [ ] 작성한 코드에 대한 테스트 코드 작성 (기능 추가 / 버그 개선)
- [ ] 작성한 코드 문서화 (기능 추가 / 버그 개선)
## PR Type
해당 PR이 포함하는 내용 체크:
- [ ] 패키지
- [ ] 패키지 추가
- [ ] 패키지 설정 변경
- [ ] CI
- [ ] CI 구성 추가
- [ ] CI 설정 변경
- [ ] 문서화
- [ ] 신규 문서 추가
- [ ] 기존 문서 변경
- [ ] 신규 기능 추가
- [ ] 버그 수정
- [ ] 코드 개선
- [ ] 성능 개선
- [ ] UI 개선
- [ ] 성능에 영향을 끼치지 않는 수정
- [ ] 테스트
- [ ] 테스트 코드 추가
- [ ] 기존 테스트 코드 변경
- [ ] 커밋 되돌리기
- [ ] 기타
## 해당 PR에 대한 설명
## 스크린샷
## 기타 정보
|
코드리뷰
코드리뷰 시 확인해야 할 기능
- 적절한 변수명, 함수명
- 매직 넘버 상수화
- if문 depth 2단계 이하 유지
- 중복된 코드 제거
- 함수 분리
- 전반적인 설계
코드 리뷰 예시
1
2
3
4
| + modifyCard(e){
+ e.preventDefault();
+ const data = `cardId=${this.data.cardId}&todoJob=${this.data.todoJob}..
+ fetch("/card", {
|
💡 api 통신하는 부분에서 options 값이 중복이 발생하고 있습니다. 이를 해결하기 위해 api 통신하는 부분을 캡슐화하여 분리하는 것이 좋습니다. 그리고 지금 data 부분이 왜 querystring으로 구성되어있는지 잘 모르겠습니다. json 형태로 데이터 통신이 가능할텐데 말이죠.
코드 리뷰 더 잘하는 법
- 잘한 부분은 칭찬합니다. (1PR당 최소 1개 이상)
- 코드리뷰는 주관적일 수 밖에 없기 때문에 무조건 수용해서는 안됩니다.
- 질문을 하기 전에 충분히 구글링을 했는지 생각해봅니다.
- 본인이 생각하고 있는 것을 맞고 틀리고를 떠나서 표현합니다.
- 피드백에 대해 반드시 감사함을 나타냅니다.
- 상대방이 기분이 상할 수 있는 말투는 자제해야 합니다.