変更のレビュー前にコミットとブランチを比較する

レビューの前に、何を知りたいかを決めます。「このコミットは何を変えたか」と「このブランチは分岐後に何を変えたか」では、同じブランチ名でも差分が変わる場合があります。

Mac でコミット済みの変更を読むアプリを探している場合は、先に Yenpo の Git 差分ビューアーの使い方と制限をご覧ください。

比較を開く

feature を main と比較する場合は、次の手順の名前を実際のブランチに置き換えてください。

ローカル Git リポジトリを開き、サイドバーの Compare Versions… を押します。
Commit から Compare に切り替えます。
From（base）の Local branches で main、To（head）の Local branches で feature を選びます。各列に独立した参照元と検索欄があります。
feature 側の作業を見るなら Since the branches split、先端同士なら Direct comparison を選びます。違いは次節で説明します。
要約のブランチ名と短いコミット ID を確認します。逆なら Swap で入れ替え、View Changes を押します。
変更ファイルのツリーからファイルを選び、インライン差分を読みます。

origin/main を使うなら From 列で Remote branches を選びます。これはローカルに保存済みのリモート追跡参照で、サーバーの最新表示ではありません。新しいリモートコミットが必要なら、普段の Git クライアントで更新し、選択画面を開き直してください。

比較は特定のコミットに固定されます。後からブランチが進んでも、そのレビューは選択時のコミットのままです。新しい先端を読む場合は比較を開き直します。

モードを選ぶ

知りたいこと	モード	比較対象
一つのコミットは何を変えたか	Commit	第一親 → 対象コミット。ルートコミットは空のツリーと比較
二つのブランチの先端は今どう違うか	Direct comparison	base の先端 → head の先端
head は分岐後に何を変えたか	Since the branches split	merge base → head の先端

次の履歴を考えます。

      M1──M2  main
     /
O───X
     \
      F1──F2  feature

main → feature の直接比較は M2 と F2 を比べ、両側の作業を含みます。Since the branches split は X と F2 を比べるため、通常「feature が何を追加したか」に適しています。最終的なマージを再現するものではなく、競合の有無も分かりません。

マージコミットの Commit モードは第一親とのみ比較します。各親に対する差分ではなく、マージを見る一つの視点なので、質問に合うか確認してください。

正確なリビジョンの組を確認する

変更ツリー上部のリビジョン行にポインターを重ねると、完全なコミット ID を確認できます。Direct comparison では選択した From と To、Since the branches split では base に merge-base(...) と表示され、From の先端ではなく共通祖先の ID になります。

同じ版を Git で確認するには、リポジトリで次の読み取り専用コマンドを実行します。BASE_COMMIT_OID と HEAD_COMMIT_OID を Yenpo に表示された二つの完全な ID に置き換えます。

git show --no-patch --format='%h %s' BASE_COMMIT_OID HEAD_COMMIT_OID
git diff --stat BASE_COMMIT_OID HEAD_COMMIT_OID --

最初のコマンドでコミットを特定し、次でコミット済みのツリーの差分を要約します。未コミットのファイルは対象外です。過去のレビューを確認するときは記録した ID を使ってください。ブランチ名はすでに新しいコミットを指している場合があります。

周辺のコードとともに差分を読む

変更ツリーからは読み取り専用のインライン差分を開けます。比較対象と現在のファイルを並べて開けるため、呼び出し元やテストを考察する前に各タブの版を確認します。作業ツリーには選択した head にない変更があるかもしれません。

動作を変える変更では、編集行の先まで読みます。

新しいコードに到達できる呼び出し元を探します。
実行条件となる入力や状態を特定します。
戻り値、エラー、副作用を呼び出し元まで追います。
既存テストがその状態へ実際に到達するか確認します。

「handles concurrent reads」というテストでも、実際は二つの呼び出しを順番に行うだけかもしれません。名前ではなく準備とアサーションを読みます。Promise キャッシュのレビューで具体例を確認できます。

AI Reader にレビューを依頼する

比較ヘッダーの Ask AI to review this comparison を使います。選択中の比較を添付した下書きを作り、まだ送信はしません。比較チップと文章を確認し、論点を調整して送信します。未接続なら先にモデルプロバイダーを接続してください。

例えば、次のように依頼します。

キャンセルとエラー処理の回帰に注目してレビューしてください。各指摘に、変更箇所、発生する状態、ユーザーに見える影響、根拠のコードを示してください。base にもあった問題は分けてください。

提案された条件が選択したコミットで実際に起こるか確認します。コードだけで順序が分からなければ、再現例や小さなテストを求めて自分で実行してください。回答中のテストはまだ実行されていません。

修正したい場合

Git 比較の会話は常に読み取り専用です。修正には現在の作業ツリーで通常の会話を始め、Allow Edits を有効にします。比較は参照用に残しておきます。

その後、作業ツリーの差分を読み、プロジェクトの確認を自分で実行します。停止しても書き込み済みのファイルは元に戻りません。作業ツリーに元から変更があった場合は修正と区別してから、コミットする内容を決めてください。