GitのDiffの説明:例を交えた完全ガイド

Git diffは、コードリポジトリで起こっている変更を確認するための窓口です。基本的に、それはさまざまな状態のファイルの違いを表示するコマンドであり、現在の作業内容とすでにステージングされた内容を比較したり、ブランチやコミット間の変更を比較したりすることができます。Gitが「何が変わったのか?」という質問に答える方法と考えてください。コマンドgit diffを実行すると、Gitはファイルの内容を行ごとに分析し、追加された部分、削除された部分、変更された部分を特定し、変更点や場所を明確に示す標準化された形式で情報を提示します。

Git diffは、コミットする前に変更内容を明確に把握することで、開発者がコード品質を確保するのに役立ちます。ここでは、この重要なコマンドを効果的に使用する方法について、基本的な比較から開発ワークフローやチームのコラボレーションを向上させるための高度なテクニックまでをカバーします。

前提条件

このチュートリアルに従うには、これらのGitの概念に精通している必要があります:

  • 基本的なGitワークフロー(init、add、commit)
  • Gitリポジトリとその構造
  • ブランチとその動作方法
  • コミットとコミット履歴
  • ステージングエリア(インデックス)

これらの概念を復習する必要がある場合は、次のリソースが役立ちます:

必要なもの Gitがシステムにインストールされている必要です。すべてのコマンドはターミナルまたはコマンドプロンプトで実行できます。

開発者にとってGit Diffが重要である理由

どんな開発者も、ソロで作業している場合でも、数百人のチームで作業している場合でも、自分のコードに何が変更されたかを知る必要があります。git diffがないと、どの行が変更されたかを推測するしかなく、トラブルシューティングや共同作業がほとんど不可能になります。

Gitのdiffは変更管理に不可欠であり、効果的なレビュープロセスを通じて品質の高いソフトウェアを構築するための基盤となります。変更を調査する際、git diffは変更内容だけでなく、なぜそれらの変更が重要なのかを理解するための文脈を提供します。

このコードの進化に対する直接的な可視性は、チームが標準を維持し、バグが本番環境に到達するのを防ぐのに役立ちます。

プロジェクトが複雑さを増すにつれて、git diffはいくつかの主要な理由で本当に不可欠となります:

  • 変更の検証: コミットしようとしている内容を正確に確認し、デバッグコードや関連のない変更が誤って含まれるのを防ぎます
  • 知識の移転:ファイル全体を読まずにチームメイトの行動を理解する
  • 紛争解決:マージ中に変更がどこでどのように競合しているかを正確に特定する
  • 歴史的分析:バグを追跡したり機能の進化を理解するために特定の変更がいつ導入されたかを追跡する
  • ターゲットコードレビュー:コードの実際に変更された部分に焦点を当て、時間を節約し、レビューの品質を向上させます

効果的にgit diffを使用するには、これらの比較を可能にする基礎となるアーキテクチャを理解する必要があります – Gitの「Three-Tree」モデル。

GitのThree-Treeアーキテクチャ

git diffを理解するには、まずGitの基本的な「three-tree」アーキテクチャを把握する必要があります。この名前にもかかわらず、これらはファイルシステム内の実際の木ではなく、コードが存在する3つの異なる状態です。

これらの状態は、Gitが同時に追跡するプロジェクトの3つの異なるバージョンと考えることができます:ワーキングディレクトリ(実際のファイル)、ステージングエリア(またはインデックス、変更がコミットの準備が整えられる場所)、およびリポジトリ(.gitディレクトリに保存されているプロジェクトのコミット履歴)。

出典: Hashnode

ワーキングディレクトリには、現在積極的に編集しているファイルが含まれています。ここでコードを書き、変更を加え、作業をテストします。ステージングエリアは、次のコミットに含めるべき変更を選択する準備ゾーンとして機能します。これは、パッケージ(変更内容)が出荷される前に整理される積み込みドックのようなものと考えることができます。

リポジトリは、プロジェクトの完全な履歴をコミットのシリーズとして保存し、特定の時点でのコードのスナップショットをリンクして歴史的な連鎖を形成します。

Git diff は、これらの3つの状態を様々な組み合わせで比較することによって機能します。 git diff を実行すると、引数なしで、作業ディレクトリとステージングエリアを比較し、まだステージングされていない変更点を表示します。

git diff --staged を使用すると、ステージングエリアと直前のコミットを比較し、次のコミットに含まれる内容を表示します。

そしてgit diff HEADは、作業ディレクトリを直近のコミットと比較し、ステージング状態に関係なくすべての未コミット変更を表示します。

これらの比較ポイントは、Gitのすべてのdiff操作の基盤を形成します:

  • 作業ディレクトリ ↔ ステージングエリア: どの変更をステージしていないか? (git diff)
  • ステージングエリア ↔ リポジトリ: 次にコミットされるステージングされた変更は何ですか? (git diff --staged)
  • 作業ディレクトリ ↔ リポジトリ: 作業ファイルと最後のコミットとの総差異は何ですか? (git diff HEAD)
  • コミット間:コードは歴史の特定のポイント間でどのように進化しましたか?(git diff commit1-hash commit2-hash

このアーキテクチャを理解することで、コードベース内で変更された内容、場所、および時期を正確に特定するためにgit diffを効果的に使用するために必要な精神的なモデルが得られます。

このアーキテクチャの理解があることで、これで、実際にgit diffコマンドをどのように使用して、コードの進化をこれらの3つの状態間で把握するかを探求できるようになりました。

基本的なGit Diffの使い方

git diffが実行されるサンプルデータ分析プロジェクトを作成しましょう。Pythonスクリプト、CSVデータ、およびテキストファイルを含む小さなリポジトリを設定し、このチュートリアルを通じて変更できるようにします。

# プロジェクトの作成と初期化 mkdir data-analysis-project cd data-analysis-project git init # 初期ファイルの作成 echo "# Data Analysis Project\nA sample project to demonstrate git diff functionality." > README.md echo "import pandas as pd\n\ndef load_data(filename):\n return pd.read_csv(filename)\n\ndef analyze_data(data):\n return data.describe()" > analysis.py echo "id,name,value\n1,alpha,10\n2,beta,20\n3,gamma,30" > data.csv echo "DEBUG=False\nDATABASE_PATH=./data/" > config.txt echo "def normalize_data(data):\n return (data - data.min()) / (data.max() - data.min())" > utils.py # 最初のコミットを作成 git add . git commit -m "Initial commit with basic project structure" # ディレクトリ構造を確認 > tree . ├── README.md ├── analysis.py ├── config.txt ├── data.csv └── utils.py

現在、プロジェクトにはバージョン管理された5つのファイルがあり、さまざまなdiffシナリオを示す基盤ができました。進行するにつれて、これらのファイルを変更して、git diffが異なる状況で変更を明らかにする方法を紹介します。

git diffの結果を理解する

git diffコマンドを実行すると、出力は変更点を明確に示すように設計された標準化された形式に従います。以下のanalysis.pyファイルを変更して、diffを実演しましょう:

# 新しい関数を持つanalysis.pyを更新 echo "import pandas as pd\n\ndef load_data(filename):\n return pd.read_csv(filename)\n\ndef analyze_data(data):\n return data.describe()\n\ndef visualize_data(data):\n return data.plot(kind='bar')" > analysis.py

次に、生成されたgit diffを調べてみましょう:

git diff

次のような出力が表示されます:

注意: git diffの出力を終了するには、端末で「q」を押してください。

この出力を解説します:

  1. ヘッダー(diff --git a/analysis.py b/analysis.py)は比較されているファイルを示し、それはanalysis.py
  2. です。ファイルのメタデータindex db0e049..a7a7ab0 100644)は、前後のバージョンの内部Git識別子を示します。
  3. ファイルマーカー--- a/analysis.py and +++ b/analysis.py)は、”前”と”後”のファイルを示します
  4. ハンクヘッダー@@ -5,3 +5,6 @@)は、影響を受けた行を示します。この表記は次のように解釈できます:
  • -5,3元のファイルの5行目から開始して、3行が差分として表示されます
  • +5,6修正されたファイルの5行目から開始して、6行が差分として表示されます
  • これらの数字の違いは、3行が追加されたことを示しています

5. 変更された内容が、+で始まる行で追加された内容を示します

大きなファイルでは、git diff は変更を「ハンク」としてグループ化します。つまり、ファイル内の変更を含むセクションです。各ハンクには、変更を見つけるのに役立つ行番号が付いています。

作業ディレクトリとステージングエリアの比較

git diffを実行する引数なしで実行すると、作業ディレクトリ(ファイルの現在の状態)とステージングエリア(コミット準備ができた変更)を比較します。これは、変更内容を確認するのに役立ち、まだ次のコミットの準備ができていない変更を確認するのに便利です。

複数のファイルを変更してみましょう:

# README.md を更新 echo "# Data Analysis Project\nA sample project to demonstrate git diff functionality.\n\n## Installation\nRun \pip install -r requirements.txt" > README.md # data.csv を更新 echo "id,name,value\n1,alpha,10\n2,beta,20\n3,gamma,30\n4,delta,40" > data.csv

次に、README.md の変更のみをステージングしてみましょう:

git add README.md

`git diff`を今実行すると、data.csvと上記のanalysis.pyファイルに対する未ステージの変更のみが表示されます:

これにより、まだステージしていない内容に集中できます。すでにステージした内容を確認したい場合:

git diff --staged # or git diff --cached (they're synonyms)

これにより、ステージされてコミット待ちの変更がREADME.mdに表示されます。このワークフローは、クリーンで論理的なコミットを構築するために重要です。関連する作業の部分をステージし、ステージされた差分を確認して、それが一貫した変更の単位であることを検証してから、コミットすることができます。

ステージングエリアと最後のコミットの比較

git diff --stagedコマンドは、ステージングエリアと最後のコミットを比較します。これにより、次にgit commitを実行した場合に次のコミットに含まれる内容が正確に表示されます。

data.csvの変更をステージし、ステージングされた内容を調べてみましょう:

git add data.csv git diff --staged

今回の出力には、README.mddata.csvの両方の変更が表示されます。このレビューステップは、コミット前に重要です — それは意図しない変更をコミットするのを防ぐ最後の防衛線となります。

一般的なワークフローは次のようになります:

  1. 複数のファイルに変更を加える
  2. git diffを実行してすべての変更を確認します
  3. 変更を論理的なグループにステージングするためにgit add <file>を使用
  4. git diff --stagedを実行し、コミットする内容を確認
  5. ステージングされた変更をgit commit -m "Your message"でコミット
  6. 他の論理的なグループの変更に対して繰り返す

この方法論的アプローチにより、プロジェクトの進化や問題の発生箇所を特定するのが容易になります。経験を積むにつれ、これらのdiffコマンドは開発プロセスでの常連として自然と身についていくでしょう。

次のステージに進む前にコミットを行いましょう:

# data.csv と README.md をコミットする git commit -m "Modify data.csv and README.md files" # analysis.py をステージングしてコミットする git add analysis.py git diff --staged # Review the changes one more time git commit -m "Add a new function to analysis.py"

中級Git Diffテクニック

基本的なgit diffの理解ができたので、プロジェクトの変更を追跡・分析する能力を高めるためのより強力なテクニックを探っていきましょう。これらの中級概念を実証するために、引き続きデータ解析プロジェクトで作業を行います。

異なるリファレンス間の比較

Gitはリファレンス(コードの特定の状態を指すポインター)を中心に構築されています。これらのリファレンスにはブランチ、コミット、タグが含まれます。git diffコマンドを使用して、これらのリファレンスの任意の2つを比較して、それらの間に何が変更されたかを表示できます。

新しい機能を開発するための新しいブランチを作成していくつかの変更を加えましょう:

# 新しいブランチを作成して切り替える git checkout -b feature/advanced-analytics # analysis.pyファイルに新しい関数を追加する echo "import pandas as pd import numpy as np def load_data(filename): return pd.read_csv(filename) def analyze_data(data): return data.describe() def visualize_data(data): return data.plot(kind='bar') def perform_advanced_analysis(data): """Performs advanced statistical analysis on the dataset""" results = {} results['correlation'] = data.corr() results['skew'] = data.skew() return results" > analysis.py # 変更をコミットする git add analysis.py git commit -m "Add advanced analysis function"

これで、フィーチャーブランチとメインブランチを比較できます:

git diff main feature/advanced-analytics

このコマンドは、2つのブランチ間のすべての違いを示します-変更、追加、または削除されたすべてのファイル。analysis.pyに行った変更、新しいインポート、および関数を見ることができます(端末ではフルディフが切り捨てられるため、複数回エンターキーを押します)。

特定のコミットと比較するには、コミットハッシュを使用できます:

git log --oneline # Find the commit hash you want to compare with

git diff 7b3105e # Replace 7b3105e with the actual commit hash you want to compare

この比較機能は次のような場合に非常に有用です:

  • コードレビューの準備: フィーチャーブランチでのすべての変更を確認することで
  • 同僚のブランチがマージされる前に導入する変更を確認することで
  • リリースやバージョン間でコードベースがどのように進化したかを理解することで

特定のファイルを比較することで

大規模なリポジトリで作業する場合、すべての違いを見るよりも特定のファイルやディレクトリの変更に焦点を当てたいことがよくあります。Git diffはパスを指定することでこれを容易にします。

複数のファイルに変更を加えましょう:

# config.txtを更新する echo "DEBUG=True DATABASE_PATH=./data/ LOG_LEVEL=INFO" > config.txt # utils.pyを更新する echo "def normalize_data(data): return (data - data.min()) / (data.max() - data.min()) def clean_data(data): return data.dropna()" > utils.py

configファイルの変更のみを表示するには:

git diff config.txt

または、ブランチ間で特定のファイルを比較するには:

# mainとfeature/advanced-analyticsブランチ間でanalysis.pyファイルを比較する git diff main feature/advanced-analytics -- analysis.py

--コマンドの中で、Gitが参照とファイルパスを区別するのに役立ちます。これは特に以下の場合に便利です:

  • 多くのファイルを持つリポジトリで作業しながら特定のコンポーネントに焦点を当てる場合(これがよくあるケースです)
  • ブランチ間で構成がどのように変更されたかを確認する場合
  • 大量の変更の中から最も重要なファイルのみを確認する場合

コンテキストディフのオプション

Git diffには、違いが表示される方法を調整するためのいくつかのオプションが用意されており、意味のある変更に焦点を当てやすくなります。

たとえば、コードの書式変更を扱う場合、空白の違いによって重要な意味の変更が見えにくくなることがあります。書式の変更を使ってデモンストレーションしてみましょう:

# analysis.py に空白の変更を加える sed -i '' 's/ return/ return/g' analysis.py # Reduce indentation

今、標準の git diff と比較すると、空白の変更が表示されます(return ステートメントが不揃いになっているのに注目してください):

git diff analysis.py # OUT: --- a/analysis.py +++ b/analysis.py @@ -2,17 +2,17 @@ import pandas as pd import numpy as np def load_data(filename): - return pd.read_csv(filename) + return pd.read_csv(filename) def analyze_data(data): - return data.describe() + return data.describe() def visualize_data(data): - return data.plot(kind='bar') + return data.plot(kind='bar') def perform_advanced_analysis(data): Performs advanced statistical analysis on the dataset results = {} results['correlation'] = data.corr() results['skew'] = data.skew() - return results + return results

しかし、空白の変更を無視することもできます(空白のみを削除したため、変更がないことが表示されます):

git diff -w analysis.py # or --ignore-all-space

もう1つの便利なオプションは、コンテキスト行を制御することです — 変更の周囲に表示される変更のない行:

git diff -U1 analysis.py # Show only 1 line of context (default is 3) git diff -U5 analysis.py # Show 5 lines of context

これらのコンテキストオプションは特に価値があります:

  • 自動フォーマットを経たコードのレビューを行う場合
  • スタイルの変更ではなく機能の変更に焦点を当てる場合
  • 特定の変更を理解するためにより多くのコンテキストが必要な場合
  • デフォルトのコンテキストが多すぎる場合の大きなファイルでの作業

これらの中級テクニックを習得することで、コードベースの変更をレビューし理解する方法をより細かく制御でき、開発フローを効率的にし、コードレビューを効果的にすることができます。

次に進む前に最新の変更をコミットしましょう:

git add . git commit -m "Modify analysis.py, config.txt, and utils.py"

高度な Git Diff アプリケーション

git diffの中級テクニックの理解を基に、Gitのスキルを更に向上させるための高度な応用技術を探求しましょう。これらの高度な技術は、複雑なコードベースで作業する場合や大規模なチームと協力する際に特に役立ちます。

外部のdiffツールを使用する

Gitの組み込みのdiffは強力ですが、時には視覚的なdiffツールの方が複雑な変更に対してより明確になります。Gitを使用して外部ツールを設定し、diff体験を向上させることができます。

人気のある視覚的なdiffツールをセットアップしてみましょう。ここでは、例としてVSCodeを使用しますが、同様の設定はBeyond Compare、Meld、KDiff3などのツールでも機能します:

# GitをVSCodeをdiffツールとして使用するように設定する(プロジェクト固有) git config diff.tool vscode git config difftool.vscode.cmd "code --wait --diff \$LOCAL \$REMOTE" # 他の人気のあるツールを使用する場合、次のようにできます: # Beyond Compare(プロジェクト固有)を使用する場合: git config diff.tool bc3 git config difftool.bc3.path "/path/to/beyond/compare" # インストールコマンド: # Beyond Compare用: # macOSの場合: brew install --cask beyond-compare # Ubuntuの場合: sudo apt-get install beyond-compare # Windowsの場合: https://www.scootersoftware.com/download.php からダウンロード # 注意: これらの設定を現在のプロジェクトだけでなくグローバルに適用するには # 各コマンドに --global フラグを追加してください。例: # git config --global diff.tool vscode

これでgit diffを使用する代わりに、次のようにして使用できます:

git difftool main feature/advanced-analytics

これにより、変更点を表示するために構成済みのビジュアル差分ツールが開きます。Beyond Compare の見た目は以下の通りです:

ビジュアル差分ツールにはいくつかの利点があります:

  1. コンテキストを見やすくするための並列表示
  2. エディタの設定に合わせたシンタックスハイライト
  3. 変更間の高度なナビゲーション
  4. 差分を確認しながらファイルを直接編集する機能

大規模な変更や入れ子のJSONやXMLなど複雑な構造を持つファイルを見る際、ビジュアル差分ツールは理解と効率を劇的に向上させることができます。

専門の差分コマンド

Git は、特定のユースケースに対するより詳細な制御を提供する専門の差分コマンドを提供しています。これらの強力なコマンドをいくつかご紹介しましょう:

git diff-tree はツリーオブジェクト(ディレクトリ)間の差分を調べます:

# 最後の2つのコミットのハッシュを取得 LAST_COMMIT=$(git rev-parse HEAD) PREV_COMMIT=$(git rev-parse HEAD~1) # 最後のコミットでの変更を表示 git diff-tree --patch $PREV_COMMIT $LAST_COMMIT

git diff-index は、ワーキングツリーをインデックス(ステージングエリア)またはツリーと比較します:

# ワーキングディレクトリをインデックスと比較 git diff-index --patch HEAD

git diff-indexは、特にスクリプティングや自動化に役立ちます。次のコミットに含まれる変更内容をプログラムでチェックできるため、プリコミットフックや検証スクリプトに価値があります。

たとえば、CI/CDパイプラインで特定のファイルが変更されていないことを確認したり、コミットを許可する前に構成変更が特定のパターンに従っていることを確認するために使用できます。

git diff-filesは、作業ディレクトリとインデックス間のファイルの変更を表示します:

# 特定のファイルの差分を確認 git diff-files --patch config.txt

これらの専門コマンドは特に以下に役立ちます:

  • カスタムGitワークフローやスクリプトの作成
  • Gitの内部の問題のデバッグ
  • リポジトリの状態を対象とした分析の実行
  • Gitとやり取りする自動化ツールの構築

コード履歴の分析

git diffの最も強力な応用の1つは、コードが時間とともにどのように進化してきたかを分析することであり、デバッグや機能開発の理解に重要です。

特定のコミットを調べるために、特別な^!表記を使用してみましょう:

# アドバンストアナリティクスコミットのハッシュを取得します ANALYTICS_COMMIT=$(git log --oneline | grep "advanced analysis" | cut -d ' ' -f 1) # その特定のコミットで導入された変更のみを表示します git diff $ANALYTICS_COMMIT^!

^!構文は、コミットとその親を比較し、そのコミットで正確に何が変更されたかを表示するための省略形です。

<diy8特定のファイルが時間とともにどのように進化したかを追跡するには:

# analysis.py が過去3つのコミットでどのように変わったかを分析します git log -p -3 analysis.py

バグを見つける際には、git diffgit bisectを使用できます:

# リグレッションをシミュレートするバグを追加します echo "import pandas as pd import numpy as np def load_data(filename): # バグ: 誤ってデータの代わりにNoneを返す pd.read_csv(filename) return None def analyze_data(data): return data.describe() def visualize_data(data): return data.plot(kind='bar') def perform_advanced_analysis(data): results = {} results['correlation'] = data.corr() results['skew'] = data.skew() return results" > analysis.py git add analysis.py git commit -m "Update analysis.py with a hidden bug" # 今、バグが導入された時期を見つけるためにgit bisectを使用します git bisect start git bisect bad # Mark current commit as containing the bug git bisect good main # Mark the main branch as working correctly # Gitはテストするためにコミットをチェックアウトします # 見つかったら、バグを導入した正確な変更を調べることができます git diff HEAD^!

Git bisectは、バグが導入されたコミットを見つけるためにコミット履歴をバイナリサーチする強力なデバッグツールです。git diffと組み合わせることで、効率的なワークフローを作成します。

1. git bisect start コマンドで二分探索プロセスを開始します。

2. バグが含まれる現在のコミットを git bisect bad でマークします。

3. バグが存在しない既知の良いコミットを git bisect good <commit-hash> でマークします。

4. Git は自動的にテストするために履歴の中間のコミットをチェックアウトします。

5. 現在のコミットをテストした後、結果を Git に伝えます:

  • もしバグがこのコミットに存在する場合: git bisect bad
  • もしバグがこのコミットに存在しない場合: git bisect good

6. Git は、各 git bisect bad/good コマンド後にフィードバックに基づいて異なるコミットをチェックし続け、毎回検索範囲を絞ります。Git が最初の悪いコミットを特定するまで、テストとマーキングのプロセスを繰り返します。

7. 問題のあるコミットを見つけると、Git はバグを導入したコミットを示すメッセージを表示します。

8. 特定のコミットで何が変更されたかを正確に調べるには、git diff HEAD^! を使用します。

9. このコマンドにより、バグを導入したコミットで具体的にどのコードが変更されたかが表示され、デバッグ作業をその特定の変更に集中させることができます。

10. いつでも git bisect reset を使用して bisect から抜け出す これにより、bisect プロセスを開始する前のブランチに戻ることができます。

11. git bisect run <test-script> で bisect プロセスを自動化することもできます。 これは、良いコミットには 0 を返し、悪いコミットには 0 以外を返すコマンドです。

このワークフローは、特に多くのコミットがある大規模なコードベースで、デバッグ時間を劇的に短縮します。

これらの履歴解析技術は、次のような場合に非常に貴重です:

  • バグがいつ、そしてなぜ導入されたのかを見つける
  • 機能やコンポーネントの進化を理解する
  • セキュリティレビューのための変更監査
  • コード変更の背後にある意思決定プロセスを文書化する

これらの高度なgit diffアプリケーションをマスターすることで、プロジェクトの履歴を精密にたどり、問題を効率的にデバッグし、コードベースの進化についてより深い洞察を得ることができます。

Git Diffコマンドリファレンス

Git diffには、特定の状況に合わせて出力や動作をカスタマイズするための幅広いオプションが用意されています。以下は、差分解析を強化するために最も一般的に使用されるパラメータの包括的なリファレンスです:

基本比較オプション

  • git diff – 作業ディレクトリをステージングエリアと比較
  • git diff --staged(または--cached) – ステージングエリアを直近のコミットと比較
  • git diff HEAD – 作業ディレクトリを直近のコミットと比較
  • git diff <commit> – 作業ディレクトリを特定のコミットと比較
  • git diff <commit1> <commit2> – 2つの特定のコミットを比較します
  • git diff <branch1> <branch2> – 2つのブランチを比較します

Path limiting

  • git diff -- <path> – 特定のファイルまたはディレクトリに比較を制限します
  • git diff --stat – 変更の要約を表示します(変更されたファイル、挿入、削除)。大きな差分に対して非常に便利なオプションです
  • git diff --name-only – 変更されたファイルの名前のみを表示します
  • git diff --name-status – 変更されたファイルの名前とステータス(追加、変更、削除)を表示します

Display control

  • git diff -w(または–ignore-all-space)- 空白の変更を無視します
  • git diff --ignore-space-change – 空白の量の変更を無視します
  • git diff --color-words – 色付きで単語レベルの違いを表示します
  • git diff --word-diff – 異なる形式で単語レベルの差分を表示
  • git diff -U<n> – コンテキストの行数nを表示(デフォルトは3行)
  • git diff --no-prefix – diffの出力にa/およびb/接頭辞を表示しない

Content filtering

  • git diff --binary – バイナリファイルの変更を表示
  • git diff -S<string> – 指定された文字列を追加または削除する変更を検索
  • git diff -G<regex> – 指定された正規表現パターンに一致する変更を検索
  • git diff --pickaxe-all – -Sまたは-Gを使用する場合、一致するものだけでなくファイル内のすべての変更を表示します

フォーマットオプション

  • git diff --patch-with-stat – パッチと統計サマリーを表示
  • git diff --compact-summary – コンパクトな形式で統計サマリーを表示
  • git diff --numstat – 機械向けの形式で統計を表示
  • git diff --summary – 作成/削除のサマリーを表示

これらのオプションを組み合わせることで、強力でターゲットを絞った比較を作成できます。たとえば、特定のファイルでワードレベルの変更を確認する際に、空白を無視する場合:

git diff --color-words -w -- analysis.py

または、特定の関数が追加されたか削除されたかを見つける場合:

git diff -S"def perform_advanced_analysis" main feature/advanced-analytics

これらのオプションを理解することで、騒音を取り除き、重要な変更に的確に集中することができます。これにより、コードレビューや分析のワークフローが効率化されます。バグを探している、プルリクエストの準備をしている、または変更内容を理解しようとしている場合でも、適切なgit diffオプションを使用することで、タスクが大幅に容易になります。

結論

この記事では、コード変更を表示するための汎用的なコマンドとしてgit diffを探求しました。ワーキングファイルとステージされた変更の比較、ブランチやコミット間の違いの調査、より深い洞察を得るための特殊なコマンドの使用について取り上げました。Git diffをワークフローに取り入れることで、より整ったコミットを作成し、問題を早期に発見し、より良いコードレビューを行うのに役立ちます。

単独で作業している場合でもチームで作業している場合でも、git diffの習得は、コードを単に書くことから、コードベースが時間とともにどのように進化するかを理解することへと昇華させます。

Gitの専門知識をさらに高めるために、以下の貴重なリソースをチェックしてください。

これらのリソースは、git diffについて学んだことをさらに発展させ、バージョン管理のスキルを次のレベルに引き上げるのに役立ちます。

Source:
https://www.datacamp.com/tutorial/git-diff-guide