-
Notifications
You must be signed in to change notification settings - Fork 4
GitHub 규칙
No Status / Todo / In Progress / In Review / Merged
Status | 작업 설명 |
---|---|
No Status | 아직 할당되지 않은 작업 |
Todo | 할당이 정해진 할 작업 |
In Progress | 진행중인 작업 |
In Review | 작업이 끝나고 PR 리뷰를 기다리는 작업 |
Merged | Merge 완료된 작업 |
- 제목만 작성합니다.
- pr 단위와 동일합니다.
- main
- develop
- feat
- hotfix
- refactor
feat/#이슈번호-기능명(길어지면 스네이크케이스)
ex) feat/#11-button-test
-
feature
## 기능 설명
구현 내용
<!-- ## 스크린샷 - UI 관련인 경우 꼭 넣기! -->
<!-- ## 장애물 - 기능 구현 중 있었던 이슈 -->
PR 포인트
<!--리뷰어가 집중했으면 하는 부분 -->
참고 사항
<!--특이 사항이나 리뷰어가 알고 있으면 좋을 것 같은 내용 -->
궁금한 점
<!-- ## 이슈 번호 - close -->
<!--## 완료 사항-->
-
hotfix
- label로 pr 우선순위를 구분합니다.
- 1명의 approve를 받아야 merge할 수 있습니다.
- 페이지 하나는 너무 크다.
-
300줄 미만으로 작성합니다.
- mock 데이터 제외
💡 코어타임 전 고정 코드 리뷰 시간 갖기(1h)
-
P1: 꼭 반영해주세요 (Request changes)
리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.
-
P2: 적극적으로 고려해주세요 (Request changes)
작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.
-
P3: 웬만하면 반영해 주세요 (Comment)
작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.
-
P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.
-
P5: 그냥 사소한 의견입니다 (Approve)
작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.
공통시스템개발팀 코드 리뷰 문화 개선 이야기 | 우아한형제들 기술블로그
- feature→develop : squash & merge
- hotfix→develop : squash & merge
- develop→main : rebase & merge
- 긴급, 기능, 버그, 리팩토링
-
D-n 룰
-
긴급한 수정사항으로 바로 리뷰해 주세요. 앱의 오류로 인해 장애가 발생하거나, 빌드가 되지 않는 등 긴급 이슈가 발생할 때 사용합니다.
-
D-N (Within N days)
“Working Day 기준으로 N일 이내에 리뷰해 주세요”
-
💡 feat: #1 xxx 기능 추가
fix: #2 xxx 기능 수정
docs: #3 xxx 문서 수정
style: #4 xxx 코드 수정
refactor: #5 xxx 기능 수정
chore: #6 xxx 버전 수정
design: #7 xxx 페이지 수정
1 commit 1 action을 지향합니다. 최대한 작은 단위로 커밋하려고 노력합시다.