なぜプロジェクトに .gitattributes が必要なのか？
WindowsとMacが混在する環境で発生する、謎の「modified（変更あり）」エラーは、多くの開発チームにとって悩みの種です。git pull で最新コードを取得した直後、一行も書いていないのにGitが大量のファイル変更を検知することがあります。git diff を確認すると、ファイルの内容は全く同じなのに、隠れた改行コードだけが異なっているためにファイル全体が置き換わったように表示されます。
その原因は、Unix/macOSの LF (\n) とWindows의 CRLF (\r\n) の違いにあります。以前は多くの人が git config --global core.autocrlf true を使用していましたが、この方法は個人の設定に依存します。メンバーが一人でも設定を忘れたり、GUIツールの設定で上書きされたりすると、コミットログは一気に混乱に陥ります。
筆者もかつて、Docker上で動かすシェルスクリプト（.sh）のデバッグに3時間以上費やしたことがあります。原因は、Windowsユーザーが誤ってCRLFで保存してしまったことでした。その結果、Linux上のbashスクリプトが ^M: bad interpreter というエラーを吐き、実行できなくなったのです。このような初歩的なミスを防ぐために、プロフェッショナルなプロジェクトにおいて .gitattributes は必須のソリューションです。
このファイルを使用すると、リポジトリ単位でGitのルールを強制できます。同僚がどのOSを使っていようと、Gitは常にチームの共通規格に従ってファイルを処理します。
.gitattributes を30秒で導入する
プロジェクトのルートディレクトリに .gitattributes という名前のファイルを作成するだけです。.gitignore のファイル形式版だと考えると分かりやすいでしょう。作成後はリポジトリにコミットし、全メンバーにこの設定が反映されるようにします。
# ターミナルから素早くファイルを作成
touch .gitattributesファイルの構造は [ファイルパターン] [属性] という形式に従います。Gitはルールを上から順に読み込み、重複がある場合は後から記述されたルールが優先されます。
実践的なプロジェクトのための「黄金」ルールセット
あらゆる環境でプロジェクトをスムーズに動作させるために、筆者がよく適用している設定を紹介します。
1. 改行コードの自動処理 (End-of-Line)
まず、すべてのテキストファイルに対する共通ルールを設定します。以下の行を追加することで、Gitがテキストファイルを自動的に認識するようになります。Gitデータベースに保存される際はLFに自動変換され、ローカルにチェックアウトされる際はユーザーのOSに合わせて調整されます。
# すべてのテキストファイルに対するデフォルトルール
* text=autoLinuxサーバーで実行するファイルやWindowsの実行ファイルなど、特定のファイルについては明示的に指定することをお勧めします：
# Unix/Linux/Dockerで動かすスクリプトにはLFを強制
*.sh text eol=lf
*.py text eol=lf
*.js text eol=lf
# WindowsのバッチファイルにはCRLFを強制
*.bat text eol=crlf
*.cmd text eol=crlf2. バイナリファイルの保護 (Binary Files)
Gitは時として、画像やPDFファイルの改行コードまで「修正」しようと試みることがあります。これが原因でファイルが完全に破損（リビルド不能）することがあります。筆者も、Gitが勝手に改行コードを挿入したために .png ファイルのサイズが数KB増え、開けなくなった経験があります。
binary 属性を使用して、Gitに「中身をいじらないで」と伝えましょう。
# 画像ファイルをバイナリとしてマーク
*.png binary
*.jpg binary
*.jpeg binary
*.gif binary
*.ico binary
# ドキュメント、フォント、実行ファイル
*.pdf binary
*.woff binary
*.ttf binary
*.exe binary
*.dll binary3. CSVとExcelのためのちょっとしたコツ
CSVデータを扱う場合、CRLF形式を強制することで、Windows上のExcelでファイルを開いた際の列のズレや文字化けを防ぐことができます。
# CSVが常にWindowsのExcelと親和性を保つようにする
*.csv text eol=crlf既存のプロジェクトに設定を適用する方法
.gitattributes を作成しても、それ以前にコミットされたファイルは古い形式のままです。リポジトリ全体に新しいルールを適用するには、「再正規化（renormalization）」という操作が必要です：
# 1. Gitのインデックスを削除（実際のファイルは削除されないので安心してください）
git rm --cached -r .
# 2. すべてのファイルを再度追加して、Gitに新しいルールを適用させる
git add .
# 3. コミットしてサーバーにプッシュ
git commit -m ".gitattributesに従って改行コードの形式を修正"
特定のファイルがどの属性を持っているか確認するには、git check-attr コマンドを使用します。ルールに従わない「頑固な」ファイルがある場合のデバッグに最適です。
# script.sh の属性を確認
git check-attr -a script.sh
# 期待される結果:
# script.sh: text: set
# script.sh: eol: lf重要な注意点として、必ず別のブランチで十分にテストしてください。main ブランチにマージする前に、異なるOSを使っている同僚にプルしてもらい、動作を確認してもらいましょう。理不尽な「modified」が出なければ成功です。
.gitattributes を使いこなすことで、チームのコミット履歴がよりクリーンになります。改行コードの違いだけで数千行の変更が含まれるようなプルリクエストに時間を取られることもなくなります。プロジェクトを守るために、今すぐ設定しましょう。
