Gitの改行コード差分ノイズを止める — .gitattributes の text=auto と eol の使い分け

「1文字も直していないのにファイル全体が差分になる」——WindowsとmacOS/Linuxが混在するチームでよく起きる。原因はたいてい改行コードだ。Windowsは CRLF(\r\n)、Unix系は LF(\n)が標準で、コミットのたびに改行が入れ替わると差分が壊れ、レビューもマージも荒れる。個人設定の core.autocrlf に任せるとメンバー間でズレるので、リポジトリに .gitattributes を置いて改行を固定する のが本筋だ。

まず text=auto、次に必要な拡張子だけ eol で固定

.gitattributes をリポジトリ直下に置く。基本は次の1行でよい。

1
2
# テキストと判定したファイルは、リポジトリ内(=コミット)は常にLFで保存する
* text=auto

text=auto は「テキストならコミット時にLFへ正規化する」という宣言だ。チェックアウト時の改行はプラットフォームに合わせて展開される。特定の拡張子で改行を必ず固定したい場合は、eol を明示する。

1
2
3
4
5
6
7
8
9
10
11
* text=auto

# シェルスクリプトは常にLF(CRLFだと実行に失敗する)
*.sh text eol=lf
# Windows専用のバッチは常にCRLF
*.bat text eol=crlf
*.cmd text eol=crlf

# バイナリは改行変換の対象外にする(壊れる事故を防ぐ)
*.png binary
*.pdf binary

eol=lf / eol=crlf はチェックアウト時の改行まで固定するので、core.autocrlf の個人設定に関係なく全員同じ結果になる。これが core.autocrlf 依存より確実な理由だ。

既存リポジトリは「再正規化」で一括そろえ

.gitattributes を後から入れた場合、既にコミット済みのファイルはそのまま。全ファイルをルールに沿って作り直すには、再正規化を1回かける。

1
2
3
4
# .gitattributes をコミットしてから実行
git add --renormalize .
git status # 改行だけが変わったファイルが差分に出る
git commit -m "Normalize line endings via .gitattributes"

--renormalize は現在のルールで全ファイルを正規化し直す。これで以後の改行ノイズが止まる。混在が心配なファイルの現状を確認するなら、git ls-files --eol で各ファイルの working/index の改行状態を一覧できる。

1
git ls-files --eol | grep -v 'w/lf' | head

単発の変換はツールで済ませる

Gitに載っていない受領ファイルや、一度だけ改行をそろえたいテキストは、コマンドを打つより手元でさっと変換したいこともある。CRLF・LF・CRを相互変換して現在の改行コードも判定できるツールを用意しているので、単発の整形にはこちらが早い。

処理はブラウザ内で完結し、貼り付けたテキストは送信されない。チームで恒常的にそろえるなら .gitattributes、単発なら変換ツール、と使い分けると改行問題に悩まされなくなる。


Gitの改行コード差分ノイズを止める — .gitattributes の text=auto と eol の使い分け
https://blog.hashito.biz/2026/07/16/git-gitattributes-crlf-lf-normalize/
著者
hashito
作成日
2026年7月16日
著作権