コードレビューはもっと良くなることができる

2025年8月21日原文(tigerbeetle.com)

概要

GitHubのコードレビュー体験に不満を持つ開発者の視点
git-reviewツールによるローカル重視のレビュー実験の経緯
コメントをコミットとして管理するアプローチの利点と課題
実装面での摩擦や運用上の問題点
今後の展望と関連プロジェクトの紹介

GitHubのコードレビュー体験への課題意識

多くの人が GitHubのコードレビュー プロセスに不満を持つ現状
Stacked Pull Requests や interdiffレビュー が十分にサポートされていない問題
レビュー状態が リポジトリ自体に保存されない ことへの不満
Webインターフェース中心 のリモートレビュー体験が主流
- Jane Streetのような ローカル中心のワークフロー の例外

ローカルでのレビュー体験の理想

コード執筆同様、 レビューもローカルで完結 させたいニーズ
ローカルで ブランチをチェックアウト し、差分や本体コードを自在に閲覧
magit などのツールで効率的なレビュー操作
gitのステージングエリア を使い、既読ファイルの管理
テスト実行やリファクタ提案 など、自由度の高いレビュー作業

GitHubのWebレビューの不便さ

フィードバック投稿時に Webブラウザを開く必要 がある手間
HTTPラウンドトリップ による遅延や、大きな差分での テキストエリアのラグ
レビューコメントの インライン性 や 即時性 が損なわれる問題

git-reviewツールの発想と実装

レビュー内容を1コミット としてPRブランチの先頭に追加する設計
特定マーカー付きコメント でレビュー内容を管理
レビューは 著者とレビュワーがコミットを直接編集 して進行
全スレッドが//? resolvedで解決されたら リバートコミット を追加し終了

git-review運用上の課題

レビューコメントとコード修正の競合 発生リスク
deep commitや新規コミット追加時の コメント位置の衝突問題
--force-with-lease 運用の煩雑さ
コードでは厳密な履歴管理が求められる一方、レビューでは 緩やかなマージ規則 が理想
コメントのpush/popを自動化するには 複雑なツール化 が必要

今後の展望と他のアプローチ

GerritスタイルのChange-Id がgit本体に導入される可能性
- これにより コミット単位のinterdiffレビュー が実現する期待
- git-reviewのアプローチとは 部分的に非互換
- Change-Id単位で 全バージョンの履歴管理 や コメント追加 ができる可能性
現時点では Webインターフェース型レビュー に戻った現状
より良いレビュー体験 の実現に向けた他プロジェクトの紹介
- Fossil： 全てをリポジトリ内に保存 するSCM
- GerritのNoteDb： レビュー状態をgit内で管理
- git-bug： イシュー情報をgitで管理
- git-appraise： レビュー情報をgitで管理
- prr： エディタ内レビューインターフェース をGitHub API上に実装
- How Jane Street Does Code Review： 理想的なレビュー体験の実例

結論

git-reviewアプローチは 部分的には有効 だが、運用や実装の摩擦が大きい
コードレビュー体験の革新 には、今後も新たなツールや仕組みが求められる状況
ローカル主体のレビュー体験 や リポジトリ内状態管理 への挑戦は今後も重要な課題

Hackerたちの意見

コードレビューにgitを直接使うアイデア、めっちゃ魅力的だと思う。自分が変更したものをローカルで扱えるのは、クソみたいな読み取り専用のウェブUIを考えるとすごく便利だよね。なんでレビューが単一のコミットである必要があるのか、全然わからない。git-reviewの実装をシンプルに保つため？それとも、レビューする人がみんな自分のコメントや修正をPRブランチに直接コミットするアプローチがうまくいくんじゃないかって思う。そうすれば、便利に作業できるための追加ツールもいらないかもしれないし。このアイデアは、従来のGitHubフローと、Linux開発がメーリングリストやパッチを通じて整理されている方法のハイブリッドみたいだね。

└

GitHubのPRって読み取り専用って考えられてるの？チームメンバーが「提案」として修正を編集して、俺のブランチにコミットとして追加するのを承認できるんだけど。

└

なぜレビューが単一のコミットである必要があるのか理解できなかった。うん、それは確かに変だね。5人が私のコードをレビューする場合、みんな同じレビューコミットをいじるの？コードでもそんなことはしないし、意味がない気がする。レビューは、レビューされたコミットの上にコミットが必要だよ。同じコミットのレビューが5つあれば、みんなそのコミットから分岐することになる。そして、それに対処するためには、別のコミットが必要で、それも彼らの横に存在することになる。各コミットの変更プロセスは、スタックされたコミットが互いに連なったブランチになる。連なったブランチの各コミットには、コメントコミットが添付されることになる。もし議論があれば、そのコメントコミットもチェーンを形成するかもしれない。みんなが満足したら、各ブランチは一つのコミットにまとめられ、それがメインブランチにリベースされることになる。ただし、議論をしばらく保存するために新しいコミットを作る方がいいかもしれない。それが重要なポイントだね：そのデータはメインブランチの外に存在するけど、どこかに存在する必要がある。

コードをレビューする時は、ソースブランチをローカルにプルするのが好きだ。そしたら、コードをベースにソフトリセットして、自分が書いたみたいに見せる。これは、明確なコミットセットがない大きな変更をレビューする時と eerily似てる。実際の問題は、作業を小さく自己完結した単位に分けないことに気づかない人たちと一緒に働くことだ。誰もが、たくさんのファイルに対する大量のdiffをレビューして、本当に理解できるとは言えないよ。全体は部分の合計以上のものだからね。

└

簡単に使えるボタンが欲しい人向け。これだよ。

review () {
  if [[ -n $(git status -s) ]]
  then
    echo 'クリーンなツリーから始める必要があります！'
    return 1
  fi
  git checkout pristine # コミットしないブランチ
  git rebase origin/master
  branch="$1"
  git branch -D "$branch"
  git checkout "$branch"
  git rebase origin/master
  git reset --soft origin/master
  git reset nvim -c ':G' # fugitiveプラグイン付きのneovimを開く - お好みのエディタに置き換えて
  git reset --hard
  git status -s | awk '{ print $2 }' | xargs rm
  git checkout pristine
  git branch -D "$branch"
}

└

良いコミットを作り、そのコミットから良いPRを作るのは、良いコードを書くのと同じくらいのスキルだよ。残念ながら、前者が苦手な人が多すぎる。

└

私たちは、高度に並列化可能なデータサイエンスのタスクを持つチームで、リポジトリのコピーを3つチェックアウトしたよ。1つは自分たちのブランチ用、残りの2つはレビュー担当のブランチ用。

└

これ使ってるよ： https://github.com/sindrets/diffview.nvim をneovimのPRレビュー用ツールとして。基本的にvscodeのdiffツールのUIに似てるけど、vimの内蔵diffモードと統合されてる。あと、git log -p --function-contextも、あまり関与しないレビューにはすごく便利。

一歩引いて考えると、HNでスタックプルリクエストについて読んでるのがめっちゃクールだと思う。数年前にgraphite.devを始めた時、これはほとんどの開発者がFBやGoogleにいた時以外は聞いたこともないワークフローだった。3〜4年でコードレビューがどれだけ早く変わるかを見るのは楽しいね :)

└

そうだね、マジで！

└

figワークフローが恋しいな :-(

└

自分はプレ・マーキュリアルのアーカニスト難民で、まだメガPRやマージコミット、他のGitHubの問題で苦しんでるチームにGraphiteを推してる。多少ゴタゴタしたスケーリングの道を歩んでるけど、全体的には大ファンだよ :) PRとの相互運用性を持たせることから生まれる野心と結果には本当に感謝してる。これは悪夢のような問題だけど、うまくいってるだけでもすごいし、ほとんどの時間うまくいってるのはもっとすごい。Graphiteがリポジトリをハードコアな設定で初期化して、基盤となるリポジトリについてもっと多くの仮定をできるような処方的モードを強く推奨したい。マージコミットとか、リストは俺よりもよく知ってるだろうけど。これがあれば、バレットプルーフになれると思う。

Hacker Newsで議論の続きを見る

ハクソク