# 일부 개발자들, "interdiff" 코드 리뷰 선호

> Clean Markdown view of GeekNews topic #16725. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=16725](https://news.hada.io/topic?id=16725)
- GeekNews Markdown: [https://news.hada.io/topic/16725.md](https://news.hada.io/topic/16725.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-09-12T13:33:25+09:00
- Updated: 2024-09-12T13:33:25+09:00
- Original source: [gist.github.com/thoughtpolice](https://gist.github.com/thoughtpolice/9c45287550a56b2047c6311fbadebed2)
- Points: 3
- Comments: 1

## Topic Body

### 왜 일부 사람들은 "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 등이 있음

## Comments



### Comment 28863

- Author: neo
- Created: 2024-09-12T13:33:26+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=41505266) 
- 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 같은 도구가 유용함