pull 요청은 저장소의 생명력과 같습니다. 그들은 모든 것을 건강하고 움직입니다. 이 페이지에서는 완전하고 검토하기 쉬운 PR을 만들어 PR이 병합될 가능성을 높이는 방법을 자세히 설명합니다.
가능한 최고의 PR을 만들기 위해 취할 수 있는 조치는 다음과 같습니다.
커뮤니케이션
바로 코드 작성을 시작하기 전에 핵심팀과 소통하여 핵심 팀이 무엇에 관심이 있는지 알 수 있도록 하는 것이 좋습니다.
관심이 있는 문제가 있다면 문제에 관해 작업을 시작한다고 의견을 남겨주세요. 이렇게 하면 여러 사람이 같은 일을 하는 것을 방지할 수 있습니다. 팀원이 전화를 걸어 본인이 맞는지 확인합니다
문제에서 다루지 않는 아이디어가 있다면 작업을 시작하기 전에 문제를 풀어보세요. 이렇게 하면 빌드를 시작하기 전에 변경사항을 빌드하는 최선의 방법을 논의할 수 있으므로 장기적으로 작업을 줄일 수 있습니다.
설정하기
Blockly 또는 blockly-samples에 처음 참여하는 경우 개발 설정 페이지에서 시작하세요.
작게 유지
변경사항의 내용은 작지만 초점을 맞추도록 하세요. 대규모 PR 하나를 검토하는 것보다 작은 PR 여러 개를 검토하는 것이 좋습니다. 일반적인 규칙은 다음과 같습니다.
- 문제 하나를 해결하세요. 한 번에 여러 문제를 해결하려고 하지 마세요.
- 범위를 제한합니다. 일반적으로 PR에는 8시간 미만의 시간이 소요됩니다 (코드베이스의 친숙도에 따라 다름).
- 커밋을 사용합니다. PR이 약간 크다고 생각되면 git 커밋을 사용하여 변경사항을 논리적 그룹으로 분할합니다.
청결한 상태로 유지하세요.
코드 스타일이 중요한 이유 장기적인 관점에서 일관된 스타일을 사용하면 더 쉽게 유지할 수 있습니다 스타일은 변수의 이름을 지정하는 방법을 의미할 뿐만 아니라 코드를 구조화하고 주석을 작성하는 등의 방식을 다룹니다. 가능한 경우 eslint와 같은 도구를 사용하여 스타일 검사를 자동화합니다.
eslint 외에도 다음 가이드를 따르세요.
변경사항 테스트
PR을 게시하기 전에 항상 변경사항이 작동하는지 테스트해야 합니다. 그래야 나중에 돌아가서 수정할 필요가 없습니다. 다음은 다양한 카테고리의 프로젝트를 테스트하기 위한 몇 가지 아이디어입니다.
- 플러그인: 변경사항을 다루는 자동화된 Mocha 테스트를 작성합니다.
- 예: 입증된 모든 기능을 수동으로 테스트합니다.
- Codelab: 정리되지 않은 환경에서 전체 가이드를 실행하고 제공된 예시 코드를 테스트합니다.
커뮤니케이션
이는 PR 생성에서 가장 중요한 마지막 부분인 요약 작성입니다.
PR 요약을 잘 작성하면 다른 개발자가 변경사항을 검토하는 데 도움이 되므로 더 빨리 채택될 가능성이 높아집니다.
요약에는 다음과 같은 내용이 포함되어야 합니다.
- PR과 관련된 문제
- PR에 추가되는 변경사항
- 변경사항을 테스트한 방법입니다.
- 검토자가 철저히 조사해야 할 모든 항목
- 검토자에게 필요하다고 생각되는 기타 정보
요청을 작성할 때 PR 템플릿을 따르는 경우에는 아무런 문제도 없습니다. 가능한 한 간결하고 완전해야 합니다.
즐겁게 코딩하세요!