Gitで改行が変わるのはなぜ？gitattributesのtextとeolを一時フォルダーで試そう

同じ文章なのに、Gitでファイル全体が変わったように見える。そんなときは、改行のLF・CRLFと、Gitが保存時や取り出すときに行う変換も確認してみよう。

LFとCRLFは、改行の表し方が違う

LFはバイト値0A、CRLFは0D 0Aという並びで改行を表す。画面上は同じ改行に見えても、ファイルのバイト列は違うよ。文章の内容が同じことと、SHA-256で同じバイトになることは分けて考えよう。

gitattributesでパスごとの方針を示す

練習では、次の.gitattributesを使う。

*.txt text eol=lf

.txtをテキストとして扱い、作業ファイルを取り出す際の改行をLFへそろえる指定だよ。Gitの設定や、すでに追跡しているファイルの状態も関係するので、これを追加しただけで、既存の全ファイルが即座に書き換わるとは考えないでね。

一時リポジトリで確認する

既存プロジェクトではなく、空の練習フォルダーのターミナルで試そう。Python 3とGitを使う。

git init
printf '*.txt text eol=lf\n' > .gitattributes
python3 -c "from pathlib import Path; Path('memo.txt').write_bytes(b'hello\r\n')"
git check-attr text eol -- memo.txt
git add .gitattributes memo.txt
git show :memo.txt

check-attrではtextがset、eolがlfと確認できる。作業ファイルはCRLFで作ったが、インデックスへ入ったmemo.txtはLFに正規化される。編集部ではgit showの出力をバイト列で確認したよ。警告の有無や文面は環境の設定でも変わる。

一括正規化は別の変更として扱う

既存ファイルへgit add --renormalizeを使う操作は、広い範囲の差分を作る可能性がある。実作業で無条件に実行せず、対象と差分、チームの規約、復元方法を先に確認しよう。

今回の練習は独立したフォルダーなので、不要になったら自分で作った練習フォルダーだけを片付ける。既存リポジトリの履歴や設定を書き換える必要はないよ。

Git公式の属性説明で、text・eol・未指定時の扱いも確かめてね。