풀 요청은 저장소의 혈액과도 같습니다. 모든 것을 건강하게 유지하고 움직이게 합니다. 이 페이지에서는 PR이 병합될 가능성이 더 높은, 완전하고 검토하기 쉬운 PR을 만드는 방법을 자세히 설명합니다.
다음은 최상의 PR을 만들기 위해 취할 수 있는 단계입니다.
커뮤니케이션
코드 작성을 시작하기 전에 핵심팀에 내가 관심 있는 분야를 알리는 것이 좋습니다.
관심 있는 문제가 있으면 문제에 대해 작업을 시작하겠다는 댓글을 달고 이렇게 하면 여러 사용자가 동일한 작업을 하지 않도록 할 수 있습니다. 담당자가 답장하여 본인임을 확인합니다.
문제에 포함되지 않은 아이디어가 있다면 작업을 시작하기 전에 아이디어를 작성하세요. 이렇게 하면 빌드를 시작하기 전에 팀에서 변경사항을 빌드하는 가장 좋은 방법을 논의할 수 있으므로 장기적으로 작업량을 줄일 수 있습니다.
설정하기
Blockly 또는 blockly-samples에 기여하는 것이 처음이라면 개발 설정 페이지에서 시작하세요.
간단하게 유지하기
항상 변경사항을 작고 집중적으로 유지하세요. 하나의 큰 PR을 검토하는 것보다 여러 개의 작은 PR을 검토하는 것이 훨씬 좋습니다. 몇 가지 좋은 경험 법칙은 다음과 같습니다.
- 하나의 문제를 해결합니다. 한 번에 여러 문제를 해결하려고 하지 마세요.
- 범위를 제한합니다. 일반적으로 PR은 코드베이스에 대한 숙련도에 따라 8시간 이내에 완료되어야 합니다.
- 커밋 사용 PR이 다소 큰 것 같으면 git 커밋을 사용하여 변경사항을 논리적 그룹으로 분할합니다.
청결한 상태로 유지하세요.
코드 스타일이 중요한 이유 YouTube는 장기적으로 운영하고 있으며 일관된 스타일을 유지하면 유지보수가 더 쉬워집니다. 스타일은 변수 이름을 지정하는 방법을 의미하지만 코드 구성, 주석 작성 방법 등도 다룹니다. 가능하면 eslint와 같은 도구를 사용하여 스타일 검사를 자동화합니다.
eslint 외에도 다음 가이드를 따르세요.
변경사항 테스트
PR을 올리기 전에 항상 변경사항이 작동하는지 테스트해야 나중에 다시 돌아가서 수정할 필요가 없습니다. 다음은 다양한 프로젝트 카테고리를 테스트할 수 있는 몇 가지 아이디어입니다.
- 플러그인: 변경사항을 다루는 자동화된 Mocha 테스트를 작성합니다.
- 예: 설명된 모든 기능을 수동으로 테스트합니다.
- codelabs: 깨끗한 환경에서 전체 튜토리얼을 실행하고 제공한 예시 코드를 테스트합니다.
커뮤니케이션
PR을 작성할 때 가장 중요하고 마지막 단계인 요약 작성입니다.
좋은 PR 요약을 작성하면 다른 개발자가 변경사항을 검토하는 데 도움이 되므로 더 빨리 승인될 가능성이 높아집니다.
요약에는 다음과 같은 항목이 포함되어야 합니다.
- PR이 관련된 문제
- PR에서 추가하는 변경사항
- 변경사항을 테스트한 방법
- 검토자가 면밀히 검토하기를 원하는 모든 항목
- 검토자에게 필요하다고 생각되는 기타 정보
요청을 만들 때 PR 템플릿을 따르면 됩니다. 최대한 간결하고 완전해야 합니다.
즐겁게 코딩하세요.