▲neo 3달전 | parent | favorite | on: GN⁺: 일부 개발자들, "interdiff" 코드 리뷰 선호(gist.github.com/thoughtpolice)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 커밋은 적절한 대안이 아님 상류 변경 사항을 알 수 없음 커밋 그래프를 복잡하게 만듦 모든 사람이 Git을 사용하지 않음 interdiffs는 리뷰어가 첫 리뷰 요청부터 모든 업데이트를 따라갈 수 있게 함 여러 커밋을 하나의 리뷰 요청으로 게시할 때 유용함 Gerrit 코드 리뷰 시스템을 사용한 경험이 있으며, GitHub의 코드 리뷰는 비효율적임 Gerrit은 여러 패치를 스택으로 쌓는 것을 지원하여 작은 패치를 쉽게 리뷰할 수 있음 GitHub의 인터페이스는 포럼 스레드처럼 보이며, 재베이스를 추적할 수 없음 다양한 코드 리뷰 시스템을 사용해본 경험이 있으며, 각 시스템의 장단점이 있음 Critique는 Google의 모노레포와 맞춤형 VCS에 최적화되어 있음 Gerrit은 리뷰어에게 좋지만, 작성자에게는 불편함 GitHub는 작성자 친화적이지만, 리뷰어와 팀에게는 비효율적임 더 나은 코드 리뷰 도구를 사용하는 것이 중요함 Gerrit 코드 리뷰 시스템을 사용한 후, GitHub의 스택 PR은 불편함 GitHub는 코드 리뷰 댓글에 대한 변경 사항을 제대로 보여주지 않음 몇 가지 스크립트를 사용하여 스택 PR 작업을 더 쉽게 만듦 ejoffe/spr와 spacedentist/spr 같은 도구가 유용함
Hacker News 의견
GitHub에서 주로 사용하는 워크플로우는 작업량이 많고 협업자에게 명확하지 않음
git blame과git bisect를 깨지 않음git commit --fixup <업데이트할 커밋의 해시>를 사용함git rebase --interactive origin/main --autosquash를 사용하여 fixup 커밋을 원래 커밋과 결합함git push --force-with-lease를 사용하여 병합함GitHub의 코드 리뷰 방식은 비효율적이며, Phabricator를 사용하여 수동으로 처리했음
GitHub의 코드 리뷰 방식보다 더 나은 시스템을 원함
새로운 코드 리뷰 접근 방식을 보는 것은 항상 흥미로움
Review Board에서 interdiffs를 처음 도입했으며, 이는 코드 리뷰에서 매우 유용함
Gerrit 코드 리뷰 시스템을 사용한 경험이 있으며, GitHub의 코드 리뷰는 비효율적임
다양한 코드 리뷰 시스템을 사용해본 경험이 있으며, 각 시스템의 장단점이 있음
Gerrit 코드 리뷰 시스템을 사용한 후, GitHub의 스택 PR은 불편함