GitHub 규칙

Project

칸반보드 양식

No Status / Todo / In Progress / In Review / Merged

Status	작업 설명
No Status	아직 할당되지 않은 작업
Todo	할당이 정해진 할 작업
In Progress	진행중인 작업
In Review	작업이 끝나고 PR 리뷰를 기다리는 작업
Merged	Merge 완료된 작업

Issue

Issue 규칙

• 제목만 작성합니다.
• pr 단위와 동일합니다.

Branch

Branch 전략

• main
• develop
• feat
• hotfix
• refactor

Branch 명명

feat/#이슈번호-기능명(길어지면 스네이크케이스)

ex) feat/#11-button-test

PR

pr 템플릿

⚙️ PR 타입

 Feature
 Hotfix

✨ 기능 설명 or 🚨 문제 상황
👨‍💻 구현 내용 or 👍 해결 내용


🎯 PR 포인트

📝 참고 사항

❓ 궁금한 점

pr 규칙

• label로 pr 우선순위를 구분합니다.
  • D-n 룰
• 1명의 approve를 받아야 merge할 수 있습니다.

pr 단위

• 페이지 하나는 너무 크다.
• 300줄 미만으로 작성합니다.
  • mock 데이터 제외

Code Review

💡 코어타임 전 고정 코드 리뷰 시간 갖기(1h)

P-n rule

• P1: 꼭 반영해주세요 (Request changes)

  리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.

• P2: 적극적으로 고려해주세요 (Request changes)

  작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.

• P3: 웬만하면 반영해 주세요 (Comment)

  작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.

• P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)

  작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.

• P5: 그냥 사소한 의견입니다 (Approve)

  작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.

코드 리뷰 작성 전 참고하기

효과적인 코드 리뷰를 위해서

공통시스템개발팀 코드 리뷰 문화 개선 이야기 | 우아한형제들 기술블로그

코드 리뷰 in 뱅크샐러드 개발 문화 | 뱅크샐러드

Merge

Merge 전략

• feature→develop : squash & merge
• hotfix→develop : squash & merge
• develop→main : rebase & merge

Label

• 긴급, 기능, 버그, 리팩토링
• D-n 룰

  • 긴급한 수정사항으로 바로 리뷰해 주세요. 앱의 오류로 인해 장애가 발생하거나, 빌드가 되지 않는 등 긴급 이슈가 발생할 때 사용합니다.

  • D-N (Within N days)

    “Working Day 기준으로 N일 이내에 리뷰해 주세요”

Commit

Commit 컨벤션

feat: #1 xxx 기능 추가
fix: #2 xxx 기능 수정
docs: #3 xxx 문서 수정
style: #4 xxx 코드 수정
refactor: #5 xxx 기능 수정
chore: #6 xxx 버전 수정
design: #7 xxx 페이지 수정

Commit 단위

1 commit 1 action을 지향합니다. 최대한 작은 단위로 커밋하려고 노력합시다.