풀 요청 작성자가 병합해야하는 코드 검토 워크 플로우

16

우리 회사의 여러 팀이 전에는 본 적이없는 코드 검토 워크 플로를 연습합니다. 회사 전체의 일관성을 유지하는 데 가치가 있다는 생각으로 그 배후의 생각을 이해하려고합니다. (여러 코드베이스에 기여하고 과거의 차이점으로 인해 넘어졌습니다.)

코드 작성자가 풀 요청을 제출
검토자가 코드를 검사
- 검토자가 승인하면 "좋아요, 자유롭게 병합하십시오"라는 문구를 따라 의견을 남깁니다.
- 검토자가 우려 사항이있는 경우 "사소한 문제 X 및 Y를 수정 한 다음 병합하십시오"와 같은 주석을 남깁니다 (주요 변경 사항은 2 단계로 돌아가십시오).
코드 작성자는 필요한 경우 변경 한 다음 자신의 풀 요청을 병합합니다.

다음과 같은 우려가 있습니다.

3 단계에서 승인하는 경우이 워크 플로우는 끌어 오기 요청 작성자에게 불필요하게 보이는 왕복을 생성합니다. 이미 코드를보고있는 검토자는 즉시 코드를 병합 할 수 있습니다.
3 단계에서 변경 요청이있는 경우 이제 풀 요청을 병합하는 기관은 전적으로 PR 작성자에게만 달려 있습니다. 작성자 외에는 병합 전에 변경 사항을 보지 않습니다.

이 워크 플로우의 다른 장점이나 단점은 무엇입니까? 이 워크 플로는 다른 엔지니어링 팀에 공통적인가?

code-reviews pull-requests

— aednichols
소스

5

조직의 사람들에게 왜이 특정 워크 플로우를 선택했는지 물었습니까? 그것들은 아마도 우리보다 관련 장점을 밝힐 수있는 더 나은 위치에있을 것입니다. 우리는 단지 추측하고있을 것입니다.

— Robert Harvey

1

검토자가 " 주요 문제 X를 수정하십시오"라고 쓰면 조직에서 어떻게됩니까 ?

— Doc Brown

8

필자의 경험에 따르면, 병합 충돌이 해결 될 경우를 대비하여 원본 작성자가 병합을 수행하는 것이 가장 좋습니다. 원래 작성자는 일반적으로 병합 충돌을 해결하는 방법을 알아볼 수있는 가장 적합한 사람입니다.

— 17 of 26

여기 논리에 대해 궁금합니다. 동료들에게 물어보고 자기 답으로 작성해야합니다. 여기에는 매우 좋은 사고 과정이나 근거가있을 수 있습니다. 나는 단지 빨리 하나를 생각 해낼 수 없습니다.

— Thomas Owens

21

첫 번째 경우는 일반적으로 예의입니다. 대부분의 조직에서 병합은 일련의 자동화 된 테스트를 시작하며, 실패하면 즉시 처리해야합니다. 특히 풀 요청이 제출 된 시점과 검토 시점 사이에 상당한 지연이 발생한 경우 저자의 시간표에 병합되도록 허용하는 것이 예의이므로 예상치 못한 오류를 처리 할 시간이 있습니다. 가장 쉬운 방법은 그것들을 병합시키는 것입니다.

또한 때때로 작성자가 풀 요청이 아직 병합되지 않아야하는 이유를 나중에 알게됩니다. 다른 개발자의 PR이 우선 순위가 높고 충돌을 일으킬 수 있습니다. 아마도 그녀는 밝혀지지 않은 유스 케이스를 생각했을 것입니다. 검토 의견이 문제가 완전히 충족되기 전에 추가 조사가 필요한 브레인 스토밍을 유발했을 수 있습니다. 저자는 코드에 대해 가장 잘 알고 있으며 병합 시점에 대한 마지막 단어를 제공하는 것이 좋습니다.

두 번째로, 그것은 단지 신뢰의 문제입니다. 사람들이 사소한 문제를 재확인하지 않고 고칠 수 있다고 믿을 수 없다면, 그들은 당신을 위해 일하지 않아야합니다. 문제가 수정 후 다른 검토가 필요할 정도로 충분히 크면 트러스트 검토 자에게 요청하십시오.

즉, 때로는 다른 저자의 풀 요청을 병합하지만 일반적으로 매우 간단한 변경 또는 외부 소스에서 발생합니다. 테스트 자동화 실패를 통해 개인적으로 목자를 책임집니다.

— 칼 빌레펠트
소스

2

내가 상상했던 것보다 더 다양한 것이있는 것처럼 들린다. 자동화 된 테스트에 대한 나의 경험은 테스트가 분기가 아닌 병합되기 전에 지점에 대해 실행되므로 병합의 전제 조건이 된 것입니다. 또한 버그를 유발하는 미성숙 한 수정 프로그램도 보았습니다.

— aednichols

2

테스트는 종종 사전 조건뿐만 아니라 사후 조건으로도 실행됩니다. 코드 브랜치로 표시되지 않고 테스트가 실패하게 만드는 명백하지 않은 방식으로 여러 브랜치의 변경 사항이 충돌하는 것이 가능합니다. 내 직장에서 우리는 지점과 기본 지점을 최신 상태로 유지해야하며 병합 및 병합 후보가되기 전에 모든 테스트를 통과해야합니다. 우리는 항상 첫 번째 조건을 갖지 못했습니다. 모든 지점이 개별적으로 전달 됨에도 불구하고 실제로 마스터에 문제가 발생하기 전에

— Matthew Scharley

3

초기 작성자가 자체 풀 요청을 병합하도록하는 것이 소규모 팀에서 선호하는 워크 플로우입니다. 예를 들어 병합 충돌 해결 측면에서 이미 언급 한 기술적 이점 외에도 문화적 가치에 가치를 더한다고 생각합니다. 소유권 감각을 구축합니다.

다른 개발자가 오픈 풀 요청에 커밋을 추가 할 때 (진행중인 작업 기능 분기를 풀고 다시 밀어 넣는) 드문 경우에 초기 저자를 지정 했습니다. 이것은 자주 발생하지 않으며, 직접 대화를하거나 슬랙을 통해 발생합니다.이 추가 커밋 (다른 사람이)은 놀랍게도 착륙 해서는 안됩니다 ! 이러한 맥락에서, 초기 저자는 풀 요청을 제출 한 사람을 의미합니다.

— mkcor
소스

2

우리 조직에서는 풀 요청에 대해 매우 새롭고 귀하의 질문은 내가 생각한 것입니다.

추가하고 싶은 한 가지 관찰 : 일부 도구 (TFS 사용)에는 풀 요청과 관련된 작업 항목이있을 수 있습니다.

이 경우 검토자가 병합을 수행 한시기를 추적하는 것이 번거 로움이됩니다. 이 시나리오에서 개발자는 PR을 다시 방문하여 버그 또는 변경 요청을 열고 '해결됨'으로 표시해야합니다. 너무 일찍 '해결됨'으로 표시하면 테스터는 수정 프로그램이 이미 현재 빌드의 일부라고 생각합니다.

풀 요청의 구현에서 TFS 2017이 개선되었습니다. 이제 개발자는 모든 조건이 충족되면 (풀링 충돌, 검토 자의 승인 및 손상된 빌드 없음) 풀 요청을 자동으로 병합하도록 요청할 수 있습니다. YMMV.

— 9 룬 5
소스

1

이런 방식으로 저자는 자신의 브랜치에 대한 생각을 바꿀 수있는 기회를 가지게되며, 다른 방식으로 수행해야 할 사항을 파악하고 추가 비용을 검토를 위해 다시 청구 할 수도 있습니다.

— gnasher729
소스