【要約】改行コードの検査で69件の偽陽性を出した——作業ツリーではなくindexを見るべきだった話【Git】 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がWindows環境でのGit利用において、改行コードの整合性を検証しようとした際、検査対象の選択ミスにより大量の誤検知を招いた。作業ツリーのファイルはOSやエディタの影響を受けるため、Gitの管理状態を正しく反映していない。
- ・作業ツリー上のファイルを直接バイト単位で読み取って検査した。
- ・Gitのfilter機能による、checkout時やcommit時の自動変換を考慮していなかった。
- ・
.gitattributesの宣言と作業ツリーの実態が一致しないことを「違反」と誤判定した。 - ・結果として、実態のない69件もの偽陽性を報告する事態となった。
// Approach
開発者は、検査対象を「作業ツリー」から「Gitの内部データ」へ切り替え、用途別に取得コマンドを使い分ける手法を採用した。これにより、Gitが管理する真の状態を正確に把握することが可能となった。
- ・EOL検査には
git cat-file --filtersを使用し、展開後の状態を模した。 - ・BOM検査には
git cat-file blobを使用し、変換されない生のバイト列を確認した。 - ・PowerShell 5.1の仕様によるBOM付与を、生成元スクリプトの修正で解決した。
- ・
pre-commitとcore.hooksPathを使い、検査を自動化・共有化した。
// Result
適切な検査手法の導入により、偽陽性を排除しつつ真の課題であるBOM問題を特定・解決した。これにより、開発環境の整合性を保ちつつ、不要な差分による混乱を防ぐことに成功した。
- ・EOL違反は0件、BOM違反は3件へと正確に判明した。
- ・既存ファイルはBOMのみを除去し、巨大なdiffの発生を回避した。
- ・コミット時に自動検査が走る仕組みを構築し、再発を防止した。
- ・検査対象を「利用者に届く形」に絞ることで、実害のない差異を無視できるようになった。
Senior Engineer Insight
> Gitの内部構造、特にWorking TreeとIndexの差異を理解することは、トラブルシューティングの要である。安易な一括変換は巨大なdiffを生み、レビューを破壊するリスクがある。実害に基づいた判断基準を持つべきだ。また、
core.hooksPath を活用して検査を組織的に強制する設計は、運用の観点から極めて実戦的である。