GitHub pull 요청을 코드 검토에 효과적으로 만들기

Question

우리는 GitHub- master와 dev에 2 개의 브랜치를 가지고 있습니다. 모든 개발자가 Dev에서 변경 한 다음 끌어 오기 요청을 올리고 코드 검토를 마친 후이를 마스터에 병합합니다.

이 접근법의 문제점은 모든 개발자가 동일한 분기로 푸시되므로 변경 사항을 고유하게 식별하기가 매우 어려워집니다. 관련없는 코드조차도 풀 요청 (다른 개발자가 수행)의 일부로 제공됩니다.

코드 리뷰를 효과적으로 만드는 방법에 대해 궁금한 점이 있으십니까? 친절하게 의견을 보내주십시오.

분기 수는 최소화하고 동시에 코드 검토를보다 효과적으로 만들고 싶습니다.

Update--

우리 팀이 너무 많은 지점을 다루는 나쁜 경험을했다. 그래서 지점을 최소화하기로 결정했습니다. 그래서 우리는 두 개의 브랜치 (master와 dev)로 시작했으며 두 브랜치 모두에서 CI/CD 파이프 라인을 실행합니다. 또한 GitHub 끌어 오기 요청을 사용하여 코드를 검토하는 것은 의식적인 결정이었습니다. 분명히 코드 검토를 효과적으로 만드는 동시에 지점 수를 줄이는 것이 어렵습니다. 팀이 두 개의 지점으로 만 제한하는 엄격한 규칙은 없습니다. 우리는 관리 가능한 수준 2-5로 바꾸기를 원합니다.

나는 내 연구를 수행했으며, 코드 검토를 효율적으로 만들기 위해 가지의 수를 제한해야한다고 확신했다. 그러나 커뮤니티에 대안이 있는지 물어볼 생각이 있습니까?

Answer 1

더 많은 분기를 만들지 않고 원하는 것을 얻을 수 있다고 생각하지 않습니다. 여러 사람이 같은 지점으로 이동하는 경우 효과적으로 코드를 작성하는 것은 거의 불가능합니다.

개발자가 Dev에서 자신의 분기를 만들도록 제안한 다음 정기적으로 변경 사항을 Dev에 요청하십시오. 이 시점에서 검토 코드를 작성하면 Dev 지점이 비교적 안정적으로 유지되어야합니다. 그런 다음 Dev를 마스터로 준 표준 정기적으로 병합 할 수 있으며이 시점에서 더 포괄적 인 코드 검토 기능을 제공 할 수 있습니다.

Answer 2

로컬 변경 (자체 분기) 및 master (가장 간단한 워크 플로)에 대한 끌어 오기 요청을 트리거 할 수 있습니다.