끌어오기 요청을 사용하여 피드백 받기

끌어오기 요청은 코드를 검토하고 단일 공동 작업 프로세스로 병합할 수 있습니다. 개발자가 기능 또는 버그 수정을 추가하면 끌어오기 요청을 만들어 변경 내용을 업스트림 분기에 병합하는 프로세스를 시작합니다. 그런 다음 다른 팀 구성원에게 코드를 검토하고 승인한 후 완료할 수 있습니다. 끌어오기 요청을 사용하여 진행 중인 작업을 검토하고 변경 내용에 대한 피드백을 빨리 받아볼 수 있습니다. 그러나 변경 내용을 병합하겠다는 약속은 없습니다. 소유자는 언제든지 끌어오기 요청을 포기할 수 있습니다.

코드 검토

끌어오기 요청의 일부로 수행된 코드 검토는 명백한 버그를 찾는 것만이 아닙니다. 이것이 테스트의 대상입니다. 좋은 코드 검토는 나중에 비용이 많이 드는 문제를 초래할 수 있는 덜 명백한 문제를 catch합니다.

코드 검토는 팀의 생산성을 저하시키는 잘못된 병합 및 끊어진 빌드로부터 팀을 보호하는 데 도움이 됩니다. 검토는 병합 전에 문제를 catch하여 원치 않는 변경으로부터 중요한 분기를 보호합니다.

또한 코드 검토는 개발자 간의 공동 작업 및 통신을 장려하고 강화합니다. 그리고 팀은 기본 분기와 기능 분기 간의 모든 변경 내용에 대한 명확한 기록을 얻습니다.

다양한 검토자를 코드 검토에 사용하여 전문 지식을 교차 수분하고 문제 해결 전략을 확산합니다. 기술과 지식을 확산하면 팀이 더 강하고 탄력적입니다.

우수한 피드백 제공

고품질의 검토는 고품질의 피드백으로부터 시작됩니다. 끌어오기 요청에서 유용한 피드백에 대한 핵심은 다음과 같습니다.

• 적절한 사용자가 끌어오기 요청을 검토하도록 합니다.
• 코드가 수행하는 작업에 대해 검토자가 알고 있는지 확인합니다.
• 작업 가능하고 건설적인 피드백을 제공합니다.
• 적시에 메모에 회신합니다.

검토자를 끌어오기 요청에 할당하는 경우 올바른 검토자 집합을 선택해야 합니다. 검토자는 코드의 작동 방식을 알고 있어야 하지만 아이디어를 공유할 수 있도록 다른 영역에서 작업하는 개발자도 포함해야 합니다.

변경 내용에 대한 명확한 설명을 제공하고 수정 또는 기능이 작동하는 코드의 빌드를 제공합니다. 검토자는 동의하지 않는 변경 내용에 대한 피드백을 제공하기 위해 노력해야 합니다. 문제를 식별하고 다르게 수행할 수 있는 사항에 대해 구체적인 제안을 합니다. 이 피드백은 명확한 의도를 가지고 있으며 끌어오기 요청의 소유자가 쉽게 이해할 수 있습니다.

끌어오기 요청 소유자는 메모에 회신하거나 제안을 수락하거나 적용을 거부하는 이유를 설명해야 합니다. 일부 제안은 좋지만 끌어오기 요청의 범위를 벗어날 수 있습니다. 이러한 제안을 수행하고 끌어오기 요청과 별도로 새 작업 항목 및 기능 분기를 만들어 이러한 변경을 수행합니다.

정책을 사용하여 분기 보호

리포지토리에는 팀이 항상 양호한 상태(예: 분기)에 의존하는 몇 가지 중요한 분기가 main 있습니다. 팀은 GitHub 및 Azure DevOps와 같은 플랫폼을 사용하여 이러한 분기를 변경하기 위해 끌어오기 요청을 요구할 수 있습니다. 개발자가 보호된 분기에 변경 내용을 직접 푸시하면 푸시가 거부됩니다.

끌어오기 요청에 추가 조건을 추가하여 키 분기에서 더 높은 수준의 코드 품질을 적용합니다. 병합된 코드의 클린 빌드 및 여러 검토자의 승인은 주요 분기를 보호하기 위해 자주 사용하는 몇 가지 추가 요구 사항입니다.

자세한 정보

GitHub에는 끌어오기 요청을 사용하여 작업 변경 내용을 제안하는 방법에 대한 광범위한 설명서가 있습니다.

코드 검토에서 좋은 피드백을 제공하고 끌어오기 요청 템플릿을 사용하여 검토자에게 지침을 제공하는 방법에 대해 자세히 알아보세요. 또한 Azure DevOps는 사용하기 쉽고 필요에 따라 크기를 조정하는 풍부한 끌어오기 요청 환경을 제공합니다.