Back

diffでコードの変更を理解する

OpenReplay Team OpenReplay Team

Dec 16, 2025 · 2 min read

diffでコードの変更を理解する

すべてのコードレビューは同じように始まります。赤と緑の行が並ぶ壁を見つめ、実際に何が変更されたのかを理解しようとするのです。Gitベースのワークフローで作業するフロントエンド開発者にとって、diffを素早く正確に読み取ることは中核となるスキルです。しかし、私たちの多くは意図的な練習ではなく、自然に身につけてきました。

この記事では、unified diff形式の理解から、プロセスを高速化する最新ツールの活用まで、コードの変更を効果的に解釈する方法を解説します。

重要なポイント

  • unified diff形式は、削除された行に-、追加された行に+を使用し、hunkヘッダーで変更箇所を示します
  • git diff -wで空白のノイズを無視し、git diff --stagedでコミット前の変更をレビューします
  • Difftasticのようなセマンティックdiffツールは、生のテキストではなくコード構造を比較し、フォーマットのノイズを除外します
  • AI支援の要約はレビュー時の方向付けに役立ちますが、慎重な手動検査の代わりにはなりません

Unified Diff形式の理解

unified diff形式は、git diffの出力やプルリクエストのインターフェースで目にするものです。これを流暢に読めるようになることで、コードレビュー時に何時間も節約できます。

典型的なdiffは次のようになります:

@@ -3,5 +3,6 @@
 import React from 'react';
-const Button = ({ label }) => {
+const Button = ({ label, disabled }) => {
   return (
-    <button>{label}</button>
+    <button disabled={disabled}>{label}</button>
   );

hunkヘッダー(@@ -3,5 +3,6 @@)は、変更が発生する場所を示します。-3,5は元のファイルが3行目から5行を表示していたことを意味し、+3,6は新しいバージョンが3行目から6行を表示することを意味します。-で始まる行は削除され、+で始まる行は追加されています。マークのない行はコンテキストを提供します—通常、各変更の上下3行です。

コンテキスト行は見た目以上に重要です。ファイル全体を開かなくても、変更がファイルのどこに存在するかを理解するのに役立ちます。

日常業務でのGit Diff

git diffコマンドは、コードの異なる状態を比較します。最も一般的な比較は次のとおりです:

  • git diffは、最後にステージングしたバージョンに対するステージングされていない変更を表示します
  • git diff --stagedは、コミットしようとしている内容を表示します
  • git diff main feature-branchは、ブランチを比較します

フロントエンド開発では、Prettierのようなフォーマッターによる空白の変更がdiffを散らかすことがよくあります。git diff -wを使用して空白を無視するか、git diff --word-diffを使用して行全体の置換ではなく行内の変更を確認します。

コミット前に自分の作業をレビューする際、git diff --stagedは不可欠です。次のコミットに含まれる内容を正確に表示します—それ以上でもそれ以下でもありません。

モダンエディタでの複数ファイルのDiff

VS Codeや同様のエディタは、開発者がdiffを読む方法を変革しました。ターミナル出力をスクロールする代わりに、変更されたファイルを示すファイルツリー、インライン注釈、並列比較が得られます。

ステージングされたものとステージングされていないものの区別が視覚的になります。個別のhunkや単一行さえもステージングでき、すべてを一度にダンプするのではなく、一貫したストーリーを語るコミットを構築できます。

GitHubやGitLabのプルリクエストインターフェースは、さらに別のレイヤーを追加します。ファイルごとのナビゲーション、折りたたみ可能なセクション、特定の行に紐付けられた会話スレッドにより、大規模な変更のレビューが管理可能になります。これらのUIは、チームがコードについて議論する方法を形作ります—コメントは抽象的な説明ではなく、diff行に添付されます。

フロントエンドコードベースのためのセマンティックDiffツール

従来の行ベースのdiffには制限があります。コード構造を理解しないのです。ファイル全体で変数名を変更すると、セマンティックな変更は単純であるにもかかわらず、数十の変更行が表示されます。

Difftasticのようなセマンティックdiffツールは、tree-sitterを使用してコードを解析し、生のテキストではなく抽象構文木を比較します。結果:再フォーマットのノイズが消え、実際のロジックの変更が際立ちます。

すべてのコミットでPrettierが実行されるフロントエンドコードベースでは、これは非常に重要です。セマンティックdiffツールは、関数の移動やJSXの再フォーマットが意味のある変更ではないことを認識します—コードがどのように見えるかではなく、何を行うかの違いを示します。

これらのツールはカスタムdiffドライバーとしてGitと統合されるため、既存のワークフローで透過的に使用できます。

コードレビューにおけるAI支援Diff

GitHub Copilot、GitLabのAI機能、サードパーティツールは現在、AI支援のdiff要約を提供しています。これらは何が変更され、なぜ重要かもしれないかの平易な言葉での説明を生成します。

これらの要約は、不慣れなコードや大規模なPRをレビューする際に役立ちます。散在するhunkから意味をつなぎ合わせる代わりに、出発点が得られます:「このPRは決済フローにエラーハンドリングを追加し、関連するテストを更新します」。

しかし、AI要約は出発点であり、結論ではありません。人間だけが持つコンテキスト—なぜ特定のアプローチが選ばれたのか、どのような制約が存在したのか、変更がチームの慣習と一致しているか—を見逃します。開発者は依然として最終的な判断を行います。

実用的なワークフロー:AI要約を使用して方向付けを行い、その後実際のdiffを読んで詳細を検証し理解します。

まとめ

効果的なdiff読解は、ツールの知識と意図的な練習を組み合わせます。unified形式を理解して、ターミナル出力に怯えないようにしましょう。複雑なレビューにはエディタ統合を使用します。再フォーマットのノイズが時間を無駄にする場合は、セマンティックdiffツールを検討してください。慎重なレビューを置き換えることなく、AI要約で方向付けを加速させましょう。

目標はすべての行を読むことではなく、何が変更され、その変更が正しいかどうかを理解することです。より良いツールとより明確なメンタルモデルが、より速くそこに到達させてくれます。

よくある質問

hunkヘッダーは、両方のファイルバージョンの行番号とカウントを示します。たとえば、-3,5は元のファイルの3行目から5行を意味し、+3,6は新しいバージョンの3行目から6行を意味します。これにより、ファイル全体を開かなくても変更箇所を特定できます。

git diff -wを使用して空白の変更を無視するか、git diff --word-diffを使用して行内で変更された単語のみを強調表示します。持続的なフォーマットノイズについては、生のテキストではなくコード構造を比較するDifftasticのようなセマンティックdiffツールを検討してください。

AI要約は、特に大規模なPRや不慣れなコードの方向付けに役立ちます。ただし、プロジェクトのコンテキストやチームの慣習が欠けています。出発点として使用し、変更を承認する前に実際のdiffを読んで詳細を検証してください。

git diffを実行すると、まだステージングされていない作業ディレクトリの変更が表示されます。git diff --stagedを実行すると、ステージングされてコミットの準備ができている変更が表示されます。次のコミットに含まれる内容を正確にレビューするには--stagedを使用してください。

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.

OpenReplay

More articles from OpenReplay Blog