なぜ一部の人は「interdiff」コードレビューを好むのか
Gerritコードレビューツールの評価
- Gerritはオープンソースのコードレビューツールで、Gitリポジトリとともに動作する
- リポジトリにパッチを作成し、レビューのために提出できる
- 他の人が書いたコードを確認し、修正すべき問題を指摘する
- コードレビューは一般的に良いアイデアである
- オープンソースプロジェクトではコードがマージされうるが、これは責任と技術的負債を増加させる
さまざまなコードレビューツール
- Gerrit、GitHub、Phabricator、バグトラッカーへの
.patchファイルのアップロード、git send-emailによるメール送信など、さまざまなツールがある
- 各ツールはそれぞれ異なる度合いで機能する
理想的なパッチシリーズ
- 3つのパッチシリーズは、コードベースの進化を段階的に示す
- 変更は論理的に分離されているべきであり、各パッチが個別に適用されたものとして読めるべきである
- コードレビューを通じて、このような理想的なシリーズが検討される
GitHubのコードレビュー方式: 「diff soup」
- GitHubはもともと、元のコミットの上に新しいコミットを追加してレビューを行うことを推奨している
- これはUXデザインやさまざまな理由によって生じている
- レビュー過程で複数のコミットが追加されると、コミット間の暗黙的な関係が複雑になる
git blameやgit bisectツールの利用が難しくなる
より良い方法: 「interdiff」レビュー（別名 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などがある
1件のコメント
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は使いづらい