Gerrit 코드 검토 또는 Github의 포크 앤 풀 모델?


64

팀과 커뮤니티가 개발할 소프트웨어 프로젝트를 시작하고 있습니다. 이전에 gerrit에서 판매되었지만 Github의 포크 앤 풀 요청 모델은 더 많은 도구, 커밋을 시각화하는 방법 및 사용 편의성을 거의 제공하는 것으로 보입니다.

둘 다에 대해 약간의 경험이있는 사람에게는 각각의 장단점이 무엇이며 커뮤니티 개발의 가능성을 열어두고 싶은 팀 기반 프로젝트에 더 좋을까요?

답변:


84

Gerrit와 GitHub의 워크 플로우의 주요 차이점은 변경이 모델링되는 방식입니다.

Gerrit에서 모든 커밋은 자체적으로 변경되는 것입니다. Gerrit은 커밋 간의 관계를 보여 주지만 검토는 커밋별로 수행됩니다. 큰 변화를 작은 독립형 커밋으로 나누는 데 능숙한 팀은 Gerrit와 함께 더 많은 성공을 거둘 것입니다. 그러나 Gerrit의 모델에는 특정 커밋에 대한 연속적인 수정 사항이 포함되어 있기 때문에 이전 커밋을 수정하고 다시 푸시하거나 토픽 브랜치에서 커밋 세트를 단일 커밋하는 등 많은 개발자가 익숙하지 않은 Git 워크 플로우를 장려합니다. 범하다.

Github에서 풀 요청은 두 가지 간의 관계를 모델링합니다. Github에서 예상되는 워크 플로우는 토픽 브랜치에 하나 이상의 변경 사항을 커밋하고 (보통 리포지토리 포크에서) 반드시 브랜치와 "업스트림"브랜치간에 풀 요청을 생성하는 것입니다. 이 경우 검토중인 항목은 검토가 계속 진행되면서 계속 커지는 커밋 세트입니다. 결과는 변경 사항이 완료되면 원자 적으로 병합 될 수있는 일련의 변경 사항입니다. 풀 요청은 여러 커밋에 대해 구현 될 수있는 더 큰 범위의 변경 사항을 추적하는 데 효과적 일 수 있습니다. 또한 풀 요청은 동일한 지점에 후속 커밋을 제출하여 검토 의견에 응답하는 등 더 많은 개발자에게 익숙한 SCM 워크 플로를 지원합니다.

Github의 장점 중 가장 큰 장점은 Gerrit와 비교하여 익숙한 개발자의 수입니다. Gerrit은 Git 파워 유저들에게 인기가 있지만 마찰없이 사용하려면 중간 또는 고급 git 지식과 가파른 학습 곡선의 허용 오차가 필요합니다.

Gerrit의 장점은 Git과의 더 깊은 관계입니다. Github 풀 요청은 Git의 표준 UI에서 충분히 제거되어 Github의 웹 UI 또는 자체 API를 사용하여 풀 요청을 생성해야합니다. 변경 사항을 만들고 업데이트하기위한 Gerrit의 인터페이스는 git 프로토콜 자체입니다.


8
고마워 마틴, 흥미로운 답변입니다. 나는 Gerrit를 잠시 살펴 보려고했지만, 그것을 보류 할 것이라고 생각했다. 편집 기록과 스쿼시 커밋을 장려하면 아무 관련이 없습니다. * 8 '(
Mark Booth

15
Martin은 "Gerrit는 Git 워크 플로우를 권장합니다. 예를 들어 이전 커밋을 수정하고 다시 푸시하거나 커밋하는 커밋을 스쿼시하는 것과 같습니다. .. 한 번의 커밋으로 "정확히 맞습니다. "역사 편집"에 대한 @MarkBooth의 의견은 Martin이 말한 것이 아니라는 점을 분명히 설명합니다. (여전히 리트에,하는 동안 커밋을 개정 하지 아직 원산지 / 마스터에 통합하는) 않습니다 하지 "편집 역사"를 포함한다. 실제로이 워크 플로우는 훌륭합니다. Mark Booth의 '불량'편집 기록은 편집 한 기록을 원산지 / 마스터에게 다시 푸시하는 것입니다.
likethesky

2
@likethesky를 명확히 해 주셔서 감사하지만 '역사 편집'에 대한 문자 그대로의 해석이 다소 있습니다. 내가 우려하는 한 명시 적으로 커밋하지 않은 내용이 포함 된 변경 세트를 초래하는 것은 '역사 편집'입니다. 나는 이것이 다소 용감한 해석이며 다른 사람들이 고수하는 해석이라는 것을 알고 있습니다. * 8 ')
Mark Booth

2
그럴 수 있지. :-) "명시 적으로 커밋하지 않은 내용이 포함 된 변경 집합"의 의미를 잘 모르겠습니다. pls. 정교한 ... 나는 당신이 "WIP : 우리가 논의 한 아치 문제를 해결하려고 시도한다"와 같은 임시 (로컬 또는 원격 지사를 통해 팀원들과 공유) 커밋을 한 적이 없다고 말하지 않는다고 가정합니다 . 해당 이슈에 대한 최종 커밋 메시지로서 "문제 123 : 탄력성 및 수평 적 확장 용이성을 높이기 위해 XYZ를 리팩토링했습니다"라는 더 유용한 스쿼시 / 개정. 그러나 어쨌든, 당신은 행복하게 만드는 방법으로 git을 사용하도록 선택할 수 있습니다!
likethesky

7
이것은 환상적인 답변입니다. 덧붙여서, GitHub의 풀 요청은 더 작고 반복적 인 커밋을 촉진하며 종종 작업 제품뿐만 아니라 작업 프로세스를 보여주는 훨씬 더 설명적인 git log로 끝납니다. Gerrit의 코드 검토는 더 크고 세련된 커밋으로 훨씬 더 깨끗한 리포지토리 히스토리 (실제 병합 커밋이 거의 없음)를 촉진합니다.
tophyr
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.