Git を使っていると、差分をチェックする機会には事欠かないはず（少なくとも私はそう）。
普通に git diff とだけすると、
- ちょっと構造だけが変わったようなのは、差分量が無駄に多く見える
- 要は関連箇所のインデントが変わることで全部差分に見える
- コミット直前、実際に反映される予定の差分は見れない
- バージョン管理されていないファイルの差分は確認できない
- 差分のあったファイルだけを把握するには少々向かない
- いやまぁそれは
git statusでも使えばいいやんという感じですが
- いやまぁそれは
等と、ちょくちょく使い勝手が悪い感じがするというか。個人的にはコミット前のチェックができないのは辛すぎる。 まぁ別にコミットミスった後の微調整反映については git commit --amend なり git rebase -i なりで適宜すりゃ良いんですけど
ただ、当たり前ながら、その辺の要求に対しては適切に利用可能なオプションがあるので、別に諦める必要はないです。やりたいことをスマートに、 提供された機能で 解決するのが技能者の本懐。作り込むなら最低限に。
git diff -w : ホワイトスペース差分の無視
ホワイトスペース差分、つまり「空行の追加 / 削除」とか「半角スペースのみの変更」とかを冗長視した差分確認ができます。リファクタリングで「内部挙動のインデントだけがちょっと変わった」みたいな時に重宝します。
Git と直接関係があるわけではないですが、 GitHub で差分を見るときは、URLの末尾に ?w=1 と付与してやると同じように差分が見れるので、たまに便利。他にも色々ありそうな気はしますが、あまり把握してません。 そもそも差分チェック自体を行う時にいちいち指定するのは -w くらいな気がするし
git diff --staged : ステージング差分の確認
ステージング差分、つまり「コミット時に実際に反映される」差分の確認ができます。コミットそのものの妥当性を事前検証（最終チェックか）する時に非常に重宝します。 私は直前に3回くらい見ます
コミット予定の差分が見れるということは、 バージョン管理される前のファイルの追加についても捕捉することが出来る ので、事前に追加予定の対象ファイルを git add しておくことによって、そのファイルも単に同コマンドで「シームレスに変更差分として認識できるようになる」というメリットもあります。
ちなみに git diff --cached も同じ作用を持ち（エイリアス）、私個人は --cached の方をよく使っています。その辺は各人の運指とかの好みとかで好きな方を使うといいのではないでしょうか。
git diff --name-only : 変更があったファイル名称だけ確認
文字通り、差分のあるファイルの名前だけが出力されます。正確には相対パスか。
…とだけ言うと「いや、何に使うねん」という話なのですが、コマンドを連結して色々やるような場面では「名称だけが取得できると便利」という場面もあるので、知っておくと便利な場合がたまにあります。
# 例えば Guard に更新を捕捉させれば、検証の自動実行を発火するように仕向けられる環境なら
# 「コミット直前の反映対象」に対して touch を実行するとか
git diff --staged --name-only | xargs touch
# 「結合要求先と差分があるファイル群」に対して touch を実行するとか
git diff --name-only origin/develop | xargs touch
こいつずっと touch ばっかやってんな
というかこれは実際に業務で「出来んかな」ってなってただけなんですけどね。実際できました。
今回は検証向けに touch がやりたかっただけで、後者は理想的には origin/develop みたいな指定を抜きに upstream の設定対象を起点にしてチェックできると良かったのですが、多分その辺は git diff じゃなくて別のコマンドを使うべきなんだろうなと予想しています。
というか本当に困ったら git diff --help を見よう
まぁ実際のところ、こういうので困ったときは、普通に公式のドキュメントを閲覧するのが一番確実なんですけどね。差分確認周りは git diff --help で見れますし。