우리는 Bitbucket에서 GitHub로 전환하고 있으며 우리가 어려움을 겪고있는 한 가지는 다음과 같이 Bitbucket에서 매우 원활하게 작동하는 피어 코드 검토입니다.

1. 작성자가 풀 요청을 열었습니다 (GitHub : 동일)
2. 작성자가 동료를 검토 자로 추가했습니다 (GitHub : ?? 여러 담당자 와 함께 어려움을 겪고 있습니다 ).
3. 검토 자 :
   1. 초록색 확인 표시가있는 PR 승인 (GitHub : ??)
   2. 댓글 추가 (GitHub : 동일)
   3. 가벼운 작업을 만들었습니다 (GitHub : - [ ]PR 설명에 구문을 사용하는 경우 비슷한 종류의 작업이지만 작업에는 작동하지 않는 것이 수치입니다)
4. 검토하고 병합 할 수 있고 추가로주의를 기울여야 할 PR 목록을 한눈에 볼 수 있습니다 (GitHub : ??)

가능한 경우 타사 코드 검토 도구를 피하고 일종의 해결 방법으로 바닐라 GitHub를 유지하고 싶습니다.

내가 본 것에서, 대부분의 단계는 공식 Github 제공 프로세스가 아닌 Github에서 관례에 따라 수행됩니다.

내 고용주는 Github을 사용하고, 많은 소규모 오픈 소스 프로젝트를 운영하며 다른 오픈 소스 프로젝트에 가끔 기여합니다.

다음은 내가 일반적으로 수행 한 방법입니다.

동료를 검토 자로 추가하는 저자 :

이는 프로젝트마다 다르지만 일반적으로 할당 된 동료 검토자는 프로젝트의 모든 기고자 입니다.

오픈 소스 프로젝트는 대략적인 계층 구조 인 것 같습니다. 어쩌면 "핵심"컨트 리뷰 터가 괜찮은 후에야 컨벤션이 합병 될 수 있습니다.

현재 채용중인 상점에서 팀의 6 명 이상의 개발자 중 한 명이 승인을받은 후 병합합니다.

드문 경우지만 팀의 누군가가 주석을 사용하여 코드를 병합하기 전에 동료 검토를해야한다고 생각하는 다른 개발자를 구체적으로 부를 수 있지만, 그렇지 않은 경우 먼저 도착한 사람은 검토하고 의견을 말할 수 있습니다.

검토 자 승인 :

승인은 일반적으로 풀 요청에 "+1"또는 "lgtm"(나에게보기 좋음)이라고 설명하여 표시됩니다.

간단한 작업 :

확인란도 사용했지만 대부분의 경우 풀 요청에 대한 모든 주석은 다음과 같이 해결되는 암시 적 "작업"으로 간주됩니다.

• 라인이 주석을다는 코드 변경
• 다른 의견으로 응답

승인 된 사항과 검토해야 할 사항을 한눈에 확인 :

내가 사용하고 외모 좋은으로 저를 당신에게 끌어 오기 요청 화면에서 이러한보기를 제공 크롬에 대한 확장. 풀 요청 목록보기는 최근 Github 변경으로 인해 중단 된 것으로 보입니다.