▲

GN⁺: 일부 개발자들, "interdiff" 코드 리뷰 선호

 (gist.github.com/thoughtpolice)
3P by neo 2달전 | favorite | 댓글 1개

왜 일부 사람들은 "interdiff" 코드 리뷰를 좋아하는가

Gerrit 코드 리뷰 도구 평가

  • Gerrit은 오픈 소스 코드 리뷰 도구로, Git 저장소와 함께 작동함
  • 저장소에 패치를 작성하고 리뷰를 위해 제출할 수 있음
  • 다른 사람들이 작성한 코드를 검토하고, 수정해야 할 문제를 지적함
  • 코드 리뷰는 일반적으로 좋은 아이디어임
  • 오픈 소스 프로젝트에서는 코드가 병합될 수 있으며, 이는 책임과 기술 부채를 증가시킴

다양한 코드 리뷰 도구

  • Gerrit, GitHub, Phabricator, 버그 트래커에 .patch 파일 업로드, git send-email을 통한 이메일 전송 등 다양한 도구가 있음
  • 각 도구는 다양한 정도로 작동 가능함

이상적인 패치 시리즈

  • 3개의 패치 시리즈는 코드베이스의 진화를 단계별로 나타냄
  • 변경 사항은 논리적으로 분리되어 있어야 하며, 각 패치가 개별적으로 적용된 것처럼 읽을 수 있어야 함
  • 코드 리뷰를 통해 이러한 이상적인 시리즈가 검토됨

GitHub의 코드 리뷰 방식: "diff soup"

  • GitHub는 원래 커밋 위에 새로운 커밋을 추가하여 리뷰를 수행하도록 권장함
  • 이는 UX 디자인과 여러 이유로 인해 발생함
  • 리뷰 과정에서 여러 커밋이 추가되면, 커밋 간의 암묵적인 관계가 복잡해짐
  • git blame과 git bisect 도구의 사용이 어려워짐

더 나은 방법: "interdiff" 리뷰 (AKA git range-diff)

  • 새로운 커밋을 추가하는 대신, 원래 커밋의 새로운 버전을 게시함
  • git range-diff를 사용하여 커밋 버전 간의 차이를 비교함
  • 리뷰어는 전체 diff를 다시 읽을 필요 없이 증분 리뷰를 수행할 수 있음
  • git blame과 git bisect 도구가 더 신뢰성 있게 작동함

중간 설명: 패치 병합 전략

  • 위의 방법은 병합 전략과 독립적임 (예: git rebase vs 다중 부모 git merge 커밋)

중간 설명: git rebase가 악한지 여부

  • git rebase는 괜찮음. 단, 다른 사람들이 커밋을 기반으로 할 공개 브랜치에서는 사용하지 말아야 함

기타 노트

결론

  • interdiff 리뷰 시스템은 더 작고 빠르게 메인 브랜치에 병합되는 패치를 장려함
  • 리뷰어와 작성자 모두에게 더 나은 코드 리뷰 경험을 제공함

GN⁺의 정리

  • 이 기사는 코드 리뷰 도구와 방법론에 대한 깊이 있는 분석을 제공함
  • interdiff 리뷰 방식은 코드 리뷰의 효율성을 크게 향상시킬 수 있음
  • GitHub의 "diff soup" 문제를 해결하는 데 도움이 됨
  • 코드 리뷰 도구를 선택할 때 고려해야 할 중요한 요소들을 제시함
  • 비슷한 기능을 가진 도구로는 GitHub, Gerrit, Phabricator 등이 있음
▲
neo 2달전  [-]
Hacker News 의견

  • GitHub에서 주로 사용하는 워크플로우는 작업량이 많고 협업자에게 명확하지 않음

    • 리뷰어가 피드백을 통합한 차이를 볼 수 있게 하여 git blame과 git bisect를 깨지 않음
    • 리뷰어 피드백을 통합할 때 git commit --fixup <업데이트할 커밋의 해시>를 사용함
    • PR이 승인되면 git rebase --interactive origin/main --autosquash를 사용하여 fixup 커밋을 원래 커밋과 결합함
    • 최종적으로 git push --force-with-lease를 사용하여 병합함
    • 자동 완성 기능을 사용하여 긴 명령어를 쉽게 입력함

  • GitHub의 코드 리뷰 방식은 비효율적이며, Phabricator를 사용하여 수동으로 처리했음

    • 명시적인 UI가 있으면 더 좋을 것임

  • GitHub의 코드 리뷰 방식보다 더 나은 시스템을 원함

    • 작은 버그 수정 패치를 빠르게 병합하고 리뷰 범위를 좁히고 싶음
    • 별도의 리뷰/PR로 만들라는 주장이 있지만, 패치셋 간의 의존성 문제 발생

  • 새로운 코드 리뷰 접근 방식을 보는 것은 항상 흥미로움

    • 패치를 별도의 종속 PR로 나누는 것을 고려해보았음
    • GitContext와 같은 도구를 사용하면 PR을 작게 유지하면서 종속성을 유지할 수 있음
    • AI를 사용하여 PR과 리뷰를 요약하고 정확한 커밋 메시지를 생성할 수 있음
    • 리뷰어는 마지막 리뷰 이후의 변경 사항만 볼 수 있음

  • Review Board에서 interdiffs를 처음 도입했으며, 이는 코드 리뷰에서 매우 유용함

    • fix-it 커밋은 적절한 대안이 아님
      1. 상류 변경 사항을 알 수 없음
      2. 커밋 그래프를 복잡하게 만듦
      3. 모든 사람이 Git을 사용하지 않음
    • interdiffs는 리뷰어가 첫 리뷰 요청부터 모든 업데이트를 따라갈 수 있게 함
    • 여러 커밋을 하나의 리뷰 요청으로 게시할 때 유용함

  • Gerrit 코드 리뷰 시스템을 사용한 경험이 있으며, GitHub의 코드 리뷰는 비효율적임

    • Gerrit은 여러 패치를 스택으로 쌓는 것을 지원하여 작은 패치를 쉽게 리뷰할 수 있음
    • GitHub의 인터페이스는 포럼 스레드처럼 보이며, 재베이스를 추적할 수 없음

  • 다양한 코드 리뷰 시스템을 사용해본 경험이 있으며, 각 시스템의 장단점이 있음

    • Critique는 Google의 모노레포와 맞춤형 VCS에 최적화되어 있음
    • Gerrit은 리뷰어에게 좋지만, 작성자에게는 불편함
    • GitHub는 작성자 친화적이지만, 리뷰어와 팀에게는 비효율적임
    • 더 나은 코드 리뷰 도구를 사용하는 것이 중요함

  • Gerrit 코드 리뷰 시스템을 사용한 후, GitHub의 스택 PR은 불편함

    • GitHub는 코드 리뷰 댓글에 대한 변경 사항을 제대로 보여주지 않음
    • 몇 가지 스크립트를 사용하여 스택 PR 작업을 더 쉽게 만듦
    • ejoffe/spr와 spacedentist/spr 같은 도구가 유용함
답변달기