本記事はアフィリエイトリンクを含みます。Amazon のアソシエイトとして、TechAthletes は適格販売により収入を得ています。価格・割引・在庫は変動するため、最新の条件は各公式サイトでご確認ください。
何が困るのか
Windows と macOS / Linux が混ざったチームで、触っていないはずのファイルが git status に大量に出てくる。差分を見ると全行が変わっているが、中身の文字は同じで、改行コードだけが CRLF と LF で入れ替わっている。こういうとき「core.autocrlf を true にしろ」「いや .gitattributes に * text=auto を書け」と、人によって言うことが違う。
どちらも間違いではないが、効く範囲と優先順位が違う。両方書いてあるときにどちらが勝つのかを、公式ドキュメントの記述だけで整理する。
公式はどう書いているか
gitattributes のドキュメントは、text 属性が「未指定（Unspecified）」のときだけ core.autocrlf が使われる、と書いている。
If the text attribute is unspecified, Git uses the core.autocrlf configuration variable to determine if the file should be converted.
出典: https://git-scm.com/docs/gitattributes （取得日 2026-10-15）
つまり .gitattributes に text が書いてあれば、そちらが先で、core.autocrlf は出番がない。core.autocrlf は「属性で何も決めていないファイル」に対する既定値である。
同じ文書は、属性がとりうる状態を 4 つに分けている。名前だけ書けば Set、先頭に - を付ければ Unset、= で値を付ければ Set to a value、どのパターンにも当たらなければ Unspecified。さらに「複数のパターンが当たるときは後の行が先の行を上書きし、上書きは属性ごとに行われる」とある。
ファイル単位の優先順位も明記されている。$GIT_DIR/info/attributes が最優先、次に対象ファイルと同じディレクトリの .gitattributes、その親ディレクトリを作業ツリーのトップまで順に見て、最後にグローバルとシステム全体のファイルが最も低い優先度で参照される。グローバル側の既定の場所は core.attributesFile で指定し、未指定なら $XDG_CONFIG_HOME/git/attributes、それも無ければ $HOME/.config/git/attributes が使われる。
比べた表
text 属性の状態ごとに、チェックイン（index に入れるとき）とチェックアウトで何が起きるかを、ドキュメントの記述どおりにまとめる。
| text の状態 | 書き方 | チェックイン時 | チェックアウト時 | 判断するのは |
|---|---|---|---|---|
| Set | *.txt text |
毎回 LF に正規化（以前 CRLF で追加済みでも） | eol / 設定 / プラットフォームに従い LF→CRLF になりうる | 属性 |
| Unset | *.jpg -text |
変換しない | 変換しない | 属性 |
| auto | * text=auto |
Git がテキストと判断し、かつ CRLF で登録済みでなければ変換 | 同左 | Git の判定 |
| Unspecified | 何も書かない | core.autocrlf に従う |
core.autocrlf に従う |
設定ファイル |
text に上記以外の値を書いた場合は「未指定として扱う」とドキュメントにある。
eol 属性は作業ツリー側の改行だけを決める。こちらは text か text=auto が有効なときだけ効くが、eol を書くと text が未指定なら自動的に text が Set になる、とも書かれている。
| eol の値 | 作業ツリーでの改行 |
|---|---|
crlf |
チェックアウト時に CRLF へ変換 |
lf |
index と同じ改行をそのまま使う |
| 未指定 | core.autocrlf か core.eol で決まる。text が Set で両方未設定なら Windows は eol=crlf、それ以外は eol=lf |
古い crlf 属性との対応表もドキュメントにそのまま載っている。
crlf text
-crlf -text
crlf=input eol=lf
どちらを使うか
ドキュメントの説明に沿うと、使い分けはこうなる。
自分の作業環境だけ CRLF にしたいなら、属性を使わず core.autocrlf を設定する。ドキュメントは「どのリポジトリでも作業ディレクトリは CRLF にしたいだけなら、属性なしで設定変数を使える」として次を示している。
[core]
autocrlf = true
ただし「これはテキストファイルの正規化を強制するものではない」と注意書きがある。自分が追加するファイルは LF に正規化され、すでに正規化済みのファイルは正規化されたまま保たれる、という範囲である。
どの貢献者が追加したファイルも正規化したいなら、リポジトリに .gitattributes を置いて * text=auto を書く。これは全員に配られるので、個人の core.autocrlf の違いに左右されない。細かく制御したい場合の例として、ドキュメントは次の設定を挙げている。
* text=auto
*.txt text
*.vcproj text eol=crlf
*.sh text eol=lf
*.jpg -text
.txt、.vcproj、.sh を正規化し、.vcproj は作業ツリーで CRLF、.sh は LF、.jpg は中身にかかわらず正規化しない、という意味になる。「後の行が勝つ」規則があるので、先頭の * text=auto を各行が上書きしている。
既存リポジトリに後から text=auto を入れるときの手順も、ドキュメントに書かれている。
$ echo "* text=auto" >.gitattributes
$ git add --renormalize .
$ git status # Show files that will be normalized
$ git commit -m "Introduce end-of-line normalization"
git status で正規化してはいけないファイルが出てきたら、git add -u の前に manual.pdf -text のように text を Unset する。逆に Git がテキストと見抜けないファイルには weirdchars.txt text と明示できる。
落とし穴
core.autocrlf は属性より弱い。 .gitattributes で -text にしたファイルは、core.autocrlf = true でも変換されない。逆に text が Set なら、ユーザーが core.autocrlf を false にしていても index 側は LF に正規化される。「設定したのに効かない」と感じたら、まず属性が当たっていないかを疑う。
text=auto の判定はファイルごと。 すでに CRLF で Git に登録されているファイルは、text=auto でも変換されない。そのために git add --renormalize の手順が用意されている。
可逆でない変換は core.safecrlf で止められる。 true なら不可逆な変換を拒否し、warn なら警告だけ出して受け付ける。ドキュメントは例外も列挙している。git add 自体は作業ツリーを触らないが次のチェックアウトで触るので安全装置が働く。git apply はテキストファイルの改行を直す操作なので働かない。git diff は作業ツリーを触らないが、問題を早く見つけるために働く。
eol は改行の話であって文字コードの話ではない。 UTF-16 などは Git がバイナリ扱いするため、別の working-tree-encoding 属性がある。ただし「古い Git や JGit、libgit2 などの別実装はこの属性を解釈しない」と明記されており、対応しないクライアントが混ざると *.ps1 のようなファイルが UTF-8 のまま書き出されたり、チェックアウト時の変換が失敗してエラーになったりする、と書かれている。
builtin_ で始まる属性名は予約済み。 ユーザーが定義しても無視され、警告が出る。
自分の環境で確かめる手順
対象ファイルにどの属性がどの状態で当たっているかは、git check-attr で見られる。設定変数側の値は git config で確認する。
git --version
git check-attr text eol -- path/to/file
git config --get core.autocrlf
git config --get core.eol
git config --get core.attributesFile
check-attr の結果が unspecified なら、そのファイルの改行は core.autocrlf と core.eol で決まる。set、unset、auto、crlf、lf のどれかが出ていれば、属性ファイルの側が決めている。どの .gitattributes が効いているかは、対象ファイルのディレクトリから作業ツリーのトップまで順に遡って探せばよい。
文字コードを仕組みから押さえたいとき
改行コードの違いでどんなトラブルが起きるかを、Git の設定より手前から押さえたいときは、『[改訂新版]プログラマのための文字コード技術入門』（技術評論社）が使えます。技術評論社の書籍ページ（取得日 2026-10-21）の目次には「改行コードに起因するトラブル」「1つのファイル中の混在」「改行コードの変換」の節があります。Git の設定は扱っていません。
コメント