약속 | 이슈, 커밋, PR 가이드
| [FEAT/FIX/REFACTOR/STYLE/DOCS/TEST/CHORE] 글 제목 |
|---|
 |
- 비개발파트인 PM이나 디자이너가 보아도 개발자가 지금, 어디서, 무엇을 하는지 알 수 있도록 ID를 함께 넣어주자!
- 다짜고짜 코드 작성부터 하기 전, 해당 기능을 구현하기 위해 나는 어떠한 순서로 접근할 것인지 step by step을 생각한 후 To-Do에 해당 내용을 넣어 주자
- 작업이 완료된 Issue 는 Close 해 준다. (PR approved 되면 삭제)
| 커밋 타입 | 기능 | 사용 예시 |
|---|---|---|
| feat: | 새로운 기능 추가 | feat: 화면 전환 기능을 추가 |
| fix: | 버그 수정 | fix: 메인 화면에서 스크롤이 작동하지 않는 문제를 해결 |
| refactor: | 리팩터링 | refactor: MVC로 된 구조를 MVVM 구조로 리팩토링 |
| style: | 코드 의미에 영향이 없는 UI 수치 변경 | style: 메인화면의 bgColor의 hex 값 변경 |
| docs: | 문서 수정 | docs: readme 파일을 수정 |
| test: | 테스트 코드 작성 | test: 테스트 코드를 작성함 |
| chore: | 기타 사항 | chore: Info.plist에 push notification과 관련된 설정 변경 |
- 제목은 50자 내로 작성하기
- 본문을 작성할 때는 변경한 내용과 이유도 함께 설명하기(무엇, 왜)
- 제발 PLZ! 반드시
1번에 1개의 논리적 작업만을 커밋한다!
| [FEAT/SETTING/DESIGN/FIX/REFACTOR/DOCS] 글 제목 |
|---|
 |
[Assignee]
- 커밋이 예상보다 많아진다면 중간에 한 번 끊어서 보내기
- 한 번 PR 보낼 때 최대 commit 수는 10개로 제한하기
- PR 템플릿의 내용에 따라 작성한다.
- 줄글보다는 간결하게, 핸드폰으로 봐도 한 눈에 들어오도록, bullet-point를 최대한 사용하여 설명하자
- 리뷰어가 PR만으로도 어떤 활동을 했는지, 어떤 고민이 있는지 한 눈에 알아볼 수 있도록 작성한다.
-
작업 내용에는 어떤 이슈랑 연결되어 있는지 이슈 번호를 작성한다. -
소개란에는 다음과 같은 내용을 적는다.- 구현된 내용(스크린샷 포함): 표 안에 이미지로 넣어주면 더 좋아요.
- 사용법: 새로 추가한 기능이고, 다른 구성원들과 함께 공유해야 하는 상황이라면 코드와 간결한 설명을 함께 적는다.
- 참고 자료: 해당 기능을 구현하면서 참고했던 자료가 있다면 함께 공유하기
- 함께 논의하고 싶은 내용: 다른 개발자의 의견이 궁금하거나 / 반나절동안 고민했는데 해결하지 못한 문제가 있다면 PR을 올리며 아래 내용을 함께 적어준다.
- 무엇이 문제인지 - 해당 문제를 해결하기 위해 나는 스스로 어디까지 고민해 봤는지 - 함께 참고한 자료는 무엇인지 -
잠깐만! 자가체크는 여러분의 양심에 맡깁니다. 믿쑵니다 🙏
[Reviewer]
- 리뷰할 때는 코드가 Swift API GuideLine에 따라 맞게 작성되었는지 확인한다.
- 해당 코드에서 빠진 경우의 수는 없는지, 더 나은 방법은 없었는지 제안한다.
※ 구글의 코드 리뷰 가이드: https://madplay.github.io/post/google-code-review-guide