리뷰어가 사용할 수 있는 PR 설명 작성하기
목표: 리뷰어가 2분 안에 무엇을 볼지 결정하고, 미래의 독자가 변경 사항의 존재 이유를 이해할 수 있도록 합니다.
수집
- 베이스 브랜치를 찾고
git log --oneline <base>..HEAD및git diff --stat <base>...HEAD를 실행한 다음 diff를 읽습니다. - 이유를 찾습니다: 커밋이나 브랜치 이름에 포함된 연결된 이슈 또는 티켓 번호, 사용자의 요청, diff에 추가된 주석. 이유가 이들 중 어디에도 없다면 사용자에게 물어보고, 동기를 임의로 만들지 마십시오.
- 테스트된 내용을 확인합니다: diff 내의 테스트 파일과 사용자가 실행한 명령어. 테스트가 실행되지 않았다면 그대로 명시합니다.
.github/pull_request_template.md또는PULL_REQUEST_TEMPLATE파일이 있는지 확인합니다. 있다면 아래 구조 대신 해당 템플릿을 작성하십시오.
구조
<제목: 명령형, 70자 미만, 파일 이름이 아닌 동작 변경 사항을 나타냄>
## 왜
<문제 또는 요청을 1~3문장으로 설명. 이슈가 있다면 링크를 추가.>
## 변경 사항
- <영역별로 그룹화된 동작 수준의 항목, 파일 목록이 아님.>
## 검토 방법
- <파일 또는 영역>부터 시작하세요; 나머지는 그로부터 이어집니다.
- 위험한 부분: <가장 잘못되었을 가능성이 있는 부분과 그 이유>.
- 의도적으로 변경하지 않은 부분: <리뷰어가 기대하지만 찾을 수 없는 모든 것>.
## 테스트
- <실행한 정확한 명령어와 결과.>
- <수동 단계와 확인된 사항. 해당되는 경우 "테스트되지 않음: ...">
## 배포 / 위험
<마이그레이션, 구성, 기능 플래그, 호환성, 롤백 방법. 해당되는 경우에만 "없음">
규칙
- diff가 실제로 수행하는 작업을 설명하고, 당신이 원하는 작업을 설명하지 마십시오. 초안 작성 후 diff를 다시 읽고, diff가 지원하지 않는 주장은 삭제하십시오.
- 모든 파일을 나열하지 마십시오. 동작 변경, 새 구성, 새 종속성 및 삭제된 코드를 나열하십시오.
- 불필요한 내용("이 PR은...")을 넣지 마십시오. 저장소에서 사용하지 않는 한 이모지를 사용하지 마십시오.
- 스크린샷 또는 출력 예시: 어디에 도움이 될지 말하십시오; 직접 보지 않은 스크린샷을 절대 설명하지 마십시오.
- 제목과 본문을 복사할 수 있도록 코드 블록으로 출력하십시오. 요청하지 않는 한
gh pr create를 실행하지 마십시오.