병합 대신 풀 요청을 사용하는 이유

단순히 분기없이 마스터로 분기를 병합하는 대신 풀 요청을 사용하면 어떤 이점이 있습니까? 특히 모든 개발자가 마스터에 완전히 액세스 할 수있는 팀에서.

풀 요청은 누구나 마스터 할 수있는 경우에도 확인 및 잔액을 제공합니다.

가장 큰 장점은 코드 검토 기회를 제공한다는 것입니다. 풀을 수행하는 담당자는 코드와 테스트를보고 조직이나 팀이 보유한 모든 종류의 지침을 충족하는지 확인할 수 있습니다. 교육, 결함 또는 개선 사항 찾기, 시스템에서 팀을 교차 훈련하여 테스터에게 시스템에 대한 화이트 박스보기를 제공하는 코드 검토의 다른 이유 도 있습니다.

풀을 수행하는 사람이 시스템 아키텍처에 익숙한 경우 특히 팀 전체에 장기 비전이없는 경우 변경 사항이 시스템의 아키텍처 비전에 맞는지 확인할 수 있습니다.

풀 요청을 사용하는 습관을 개발하면 나중에 전체 팀이 마스터에 액세스 할 수 없도록 결정하는 경우 팀에 도움이 될 수 있습니다. 팀이 커질 때, 특히 제품을 처음 사용하거나 Git을 처음 사용하는 팀 구성원이있는 경우, 팀원에게 액세스 권한을 부여하지 않으면 제품 무결성이 더 안전 할 수 있습니다.

기능 분기 및 포크 + 풀 요청을 모두 수행 한 경우 풀 요청이 모두 동일한 팀 또는 회사에서 개발할 때 이점이 거의 없다고 생각합니다.

코드 검토를위한 좋은 메커니즘과 인터페이스를 제공하지만 전체 '완료된 작업'프로세스를 복잡하게하고 느리게합니다. 특히 작은 기능이 많은 경우 각각 검토 대기, 병합 및 변경 사항 등을 가져 오기 위해 마스터와 병합되는 다른 모든 기능이 있습니다. .

동일한 리포지토리에서 브랜치간에 풀 요청을 수행 할 수 있다고 말한 적이 있습니다. 분기 할 필요가 없거나 다른 권한이 없습니다.

또한 전체 방법론과 워크 플로를 고려해야합니다. 또한 발권 시스템, CI, 자동 수락 테스트 등이 있습니까? 코드 검토가 코드가 실행되기 전에 중요한 단일 검사를 제공합니까, 아니면 워크 플로의 다른 검사로 중복되는 도장 작업입니까?

Conway 's Law라는 관찰이 있습니다.

시스템을 디자인하는 조직은 이러한 조직의 커뮤니케이션 구조의 사본 인 디자인을 생성하도록 제한됩니다.

풀 요청과 관련이 있습니까? 풀 요청은 코드의 중요한 접점에서 주요 통신 채널입니다. 코드가 테스트 및 생산의 다음 단계로 넘어 가기 전에 검토, 자동화 된 테스트 및 개선의 기회를 제공합니다. 이러한 변경 사항은 취소하기가 훨씬 더 어렵고 더 많은 사람들이 더 많은 시간을 낭비합니다.

마찬가지로 Conway 's Law는 깨끗하게 분리 된 자율적 책임 영역과 잘 정의 된 인터페이스를 갖춘 마이크로 서비스 아키텍처를 원한다면 조직의 커뮤니케이션 채널에 달성하려는 아키텍처를 반영해야합니다. 즉, 5-10 명으로 구성된 소규모 팀은 특정 마이크로 서비스에 직접 커밋해야하며 팀 외부의 모든 사람은 풀 요청을 거쳐야합니다. 이를 통해 마이크로 서비스에 가장 익숙한 사람들이이를 검토하고 조언 할 수 있습니다.

모든 사람이 어느 곳에서나 직접 커밋 액세스 할 수있는 대규모 조직을 보유한 경우 가장 저항이 적은 커뮤니케이션 채널을 통해 거대한 진흙 건축을 만들 수 있습니다.

풀 요청은 대가로 거래하지 않는 경우에만 부담처럼 느껴집니다. 빌드가 항상 손상되어 일주일 동안 아무것도 할 수없는 환경에서 일했으며 누군가가 풀 요청을 제출하는 환경에서 일했으며 그들이 파산했기 때문에 그것을 검토 할 필요조차 없습니다. CI 구축, 나는 여러분에게 매 초 노력의 가치가 있다고 말합니다.

Karl Bielefeldt가 옳습니다. 나는 품질에 관한 모든 것을 추가 할 것이다.

많은 (대부분의) 상점에는 개발을 관리하기위한 공식적인 프로세스가 없습니다. 결과적으로 "저는 빌드가 항상 중단되어 일주일 동안 아무 것도 할 수없는 환경에서 근무했습니다. 풀 (pull) 요청을 제출하는 환경에서 CI 빌드를 중단했기 때문에이를 검토 할 필요조차 없으며 매 초마다 노력할 가치가 있습니다. "

정말 노력할 가치가 있습니다.

코드 검토에는 풀 요청을 사용합니다. 풀 요청을 거치지 않고 코드를 기본 개발 브랜치 (일반적으로 "개발", 때로는 "마스터")로 병합해서는 안됩니다. 리포지토리 컨트롤을 사용하여이를 강제로 시행하지는 않지만 그 이유는 개발자가 프로세스를 남용하지 않을 정도로 성숙하기 때문입니다.