Pull Request 규칙

Pull Request를 관리하는 규칙들을 정리하고 있어요.

Pull Request는 코드 리뷰와 협업의 핵심이므로, 체계적으로 작성하고 관리해야 해요.

PR 제목

PR 제목은 다음과 같은 형식으로 작성해요.

[브랜치명]

PR 제목을 작성할 때는 다음 규칙을 꼭 지켜야 해요.

1. 한국어, 영어 모두 사용 가능해요.
2. 연결된 이슈 번호를 꼭 포함해야 해요.
3. 50자 이내로 간결하게 작성해요.
4. 마침표는 사용하지 마세요.

PR 본문

PR 본문에는 다음 내용이 포함되어야 해요.

필수 항목

1. 변경 사항: 무엇을 변경했는지 명확하게 설명해요.
2. 작업 내용: 어떻게 구현했는지 설명해요.
3. 테스트 방법: 리뷰어가 어떻게 테스트할 수 있는지 설명해요.

선택 항목

1. 스크린샷/영상: UI 변경이 있다면 Before/After를 첨부해요.
2. 성능 변화: 성능 개선 작업이라면 측정 결과를 첨부해요.
3. Breaking Changes: 하위 호환성이 깨지는 변경이 있다면 명시해요.
4. 참고 사항: 리뷰어가 알아야 할 추가 정보를 작성해요.

좋은 예시

PR 작성의 좋은 예시는 다음과 같아요.

제목: [Feature] 웹뷰 브릿지 카메라 API 구현 (#123)

## 변경 내용
`CameraBridge` 클래스를 생성하여 웹뷰와 네이티브 간 통신을 처리했습니다.
`postMessage` 방식으로 웹뷰에서 카메라 요청을 받고, 결과를 콜백으로 전달했습니다.

## 관련 이슈
Resolve #23

## 스크린샷
[Before]
(이미지)

## 체크리스트
[ ] 코드가 프로젝트의 코딩 스타일을 따릅니다
[ ] 자체 코드 리뷰를 완료했습니다
[ ] 문서를 업데이트했습니다 (필요한 경우)
[ ] Breaking Changes가 없습니다

## 기타사항
(이미지)

나쁜 예시

PR 작성의 나쁜 예시는 다음과 같아요.

제목: 기능 추가 → 타입 미표기, 이슈번호 누락, 너무 모호함
제목: [Feature] 카메라 기능을 추가했습니다. (#123) → 마침표 사용, 과거형
제목: [Feature] 웹뷰 브릿지 카메라 API를 구현하고 네이티브 통신도 추가하고... (#123) → 너무 김

본문:
카메라 기능 추가했어요 → 내용이 너무 부실함, 테스트 방법 누락

리뷰 요청

PR을 생성할 때는 리뷰어를 지정해야 해요.

1. 최소 1명 이상의 리뷰어를 지정해요.
2. 해당 도메인의 전문가나 코드 오너를 포함해요.
3. 리뷰가 완료되기 전까지는 머지하지 마세요.

PR 크기

PR은 가능한 한 작게 유지해야 해요.

1. 하나의 PR은 하나의 이슈만 해결해야 해요.
2. 변경된 파일이 10개 이상이라면 PR을 분리할 수 있는지 검토해주세요.
3. 리뷰어가 30분 이내에 리뷰할 수 있는 크기가 적당해요.

Draft PR

작업이 완료되지 않았지만 피드백이 필요하다면 Draft PR을 사용해요.

1. PR 생성시에 Create draft pull request 버튼을 눌러 GitHub의 Draft PR 기능을 사용하세요.
2. 어떤 부분에 대해 피드백이 필요한지 본문에 명시해야해요.
3. 작업이 완료되면 Draft 상태를 해제하고 리뷰를 요청해야해요.

머지 방식

프로젝트마다 선호하는 머지 방식이 다를 수 있어요.

각 프로젝트에 적합한 방식을 사용하는게 좋아요.

충돌 해결

PR에서 충돌이 발생했다면 다음과 같이 처리해요.

1. 로컬에서 최신 base 브랜치를 pull 받아요.
2. 작업 브랜치에 merge 또는 rebase 해요.
3. 충돌을 해결하고 테스트해요.
4. 변경사항을 push 해요.

금지사항

의미없는 제목은 금지됩니다. ex) Feature 작업, Bug 수정

본문 없이 제목만 작성하는것도 금지됩니다.

테스트하지 않은 코드를 PR하는것도 금지됩니다.

리뷰어의 피드백 없이 강제로 머지하는것도 금지됩니다.