Git改行コード設定｜autocrlfと.gitattributesの違い

core.autocrlf は「自分のパソコンの Git」に対する改行変換の設定、.gitattributes は「リポジトリに入れて全員で共有する」改行変換の設定です。 両方があるときは .gitattributes の eol 指定が優先されるので、チームで改行コードをそろえたいなら .gitattributes に書くのが近道です。

この記事では、autocrlf（true / input / false）× .gitattributes（指定なし / text=auto / eol=lf / eol=crlf / -text）の全組み合わせで、コミット時とチェックアウト時に改行がどうなるかを実際に確かめて早見表にしました。あわせて 「LF will be replaced by CRLF」警告を再現して意味を読み解き、git ls-files --eol と git add --renormalize で既存リポジトリを直す手順を実行結果つきで示します。OS 別の推奨設定と、コピペで使える .gitattributes のひな形も載せています。

実行環境は Ubuntu 24.04 LTS、Git 2.43.0 です。Linux 上で設定を切り替えて結果を取っているため、Windows・macOS の実機では未実行です。属性の仕様は Git 公式ドキュメントの gitattributes のページを今回開いて確認しました。

改行コード設定の早見表

autocrlf × .gitattributes の組み合わせ

LF のファイルと CRLF のファイルを新しく git add してコミットし、いったん削除してからチェックアウトし直した結果です。「リポジトリ」はコミットされた中身、「作業ツリー」はチェックアウト後の手元のファイルを指します。

表から読み取れる要点は3つです。

• eol=lf・eol=crlf・-text を書いた行は、autocrlf が何であっても同じ結果になります。個人の設定の違いを吸収できるのは、この3つです。
• text=auto だけ（eol なし）の行は、autocrlf や OS によって作業ツリーの改行が変わります。
• どの組み合わせでも、テキストとして扱われたファイルの リポジトリ側は LF にそろいます（変換なしの行を除く）。

3つの設定の役割

改行コードと Git の変換のしくみ

改行コードには主に2種類あります。

同じリポジトリを Windows と macOS・Linux で一緒に使うと、エディタの設定しだいで改行コードが混ざります。改行だけが違うファイルは、中身を変えていないのに全行が変更として表示されます。

git diff --stat
git diff | cat -A | tail -5

 f.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
@@ -1,2 +1,2 @@$
-a$
-b$
+a^M$
+b^M$

^M が CR（\r）です。2行のファイルの改行を CRLF に変えただけで、2行とも変更あつかいになりました。

Git の改行変換は、次の2つのタイミングで働きます。

flowchart LR
    W[作業ツリー<br>手元のファイル] -- "git add（コミット時）<br>CRLF を LF に変換" --> I[インデックス／リポジトリ]
    I -- "git checkout（チェックアウト時）<br>LF を CRLF に変換、または変換なし" --> W

リポジトリの中は LF にそろえ、作業ツリーに取り出すときに必要なら CRLF にする、というのが Git の考え方です。autocrlf と .gitattributes は、この2つの変換を「するか・しないか」「どちらの改行にするか」を決めています。

core.autocrlf の3つの値

git config --global core.autocrlf true    # または input / false
git config --show-origin --get core.autocrlf
git config --list --show-scope | grep -i crlf

file:.git/config    false
local   core.autocrlf=false

--show-origin と --show-scope を付けると、どのファイル・どの範囲（system / global / local）で設定されているかがわかります。意図と違う値になっているときに役立ちます。

実際に確かめた結果です（.gitattributes なし）。

false のときだけ、CRLF がそのままリポジトリに入ります。 全員が false で、エディタの改行設定がそろっていない場合に、改行が混ざりやすくなります。

「LF will be replaced by CRLF」警告を再現する

警告が出る条件

core.autocrlf=true の状態で、LF のファイルを git add すると表示されます。

printf 'line1\nline2\n' > lf.txt          # LF のファイル
printf 'line1\r\nline2\r\n' > crlf.txt    # CRLF のファイル
printf 'a\r\nb\n' > mixed.txt             # 混在
git config core.autocrlf true
git add lf.txt
git add crlf.txt mixed.txt

warning: in the working copy of 'lf.txt', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'mixed.txt', LF will be replaced by CRLF the next time Git touches it

CRLF だけの crlf.txt には警告が出ず、LF を含む2つのファイルに出ています。

警告の意味

「手元のこのファイルは今 LF だが、次に Git がこのファイルを書き出すとき（チェックアウトなど）には CRLF になる」 というお知らせです。エラーではなく、git add は完了しています。リポジトリの中身が変わるわけでもありません。

直後の状態を git ls-files --eol で見ると、警告の内容がそのまま読み取れます。

git ls-files --eol

i/lf    w/crlf  attr/                   crlf.txt
i/-text w/-text attr/                   data.bin
i/lf    w/lf    attr/                   lf.txt
i/lf    w/mixed attr/                   mixed.txt

lf.txt はリポジトリ側（i/）も作業ツリー側（w/）も LF です。コミットしてからチェックアウトし直すと、こう変わります。

git commit -qm init
rm lf.txt crlf.txt mixed.txt
git checkout -- .
git ls-files --eol

i/lf    w/crlf  attr/                   crlf.txt
i/-text w/-text attr/                   data.bin
i/lf    w/crlf  attr/                   lf.txt
i/lf    w/crlf  attr/                   mixed.txt

警告のとおり、作業ツリーの lf.txt と mixed.txt が CRLF に変わりました。 バイナリの data.bin は -text と判定され、変換の対象外です。

逆向きの警告「CRLF will be replaced by LF」

core.autocrlf=input の状態で CRLF のファイルを追加すると、逆向きの警告になります。

git config core.autocrlf input
printf 'x\r\ny\r\n' > new_crlf.txt
git add new_crlf.txt
git ls-files --eol new_crlf.txt

warning: in the working copy of 'new_crlf.txt', CRLF will be replaced by LF the next time Git touches it
i/lf    w/crlf  attr/                   new_crlf.txt

リポジトリには LF で入り、手元のファイルは CRLF のままです。次にチェックアウトされると LF になります。

警告への対応の選び方

core.safecrlf の動きも確かめました。

# autocrlf=input の状態で CRLF のファイルを追加
git -c core.safecrlf=true  add new2.txt; echo "rc=$?"
git -c core.safecrlf=false add new2.txt; echo "rc=$?"

fatal: CRLF would be replaced by LF in new2.txt
rc=128
rc=0

safecrlf=true は警告を「追加を止めるエラー」に変え、false は警告を表示しなくなります。 既定は警告の表示です。Git 2.43.0 の文面は上のとおりですが、版によって警告の言い回しが異なることがあります。

git ls-files --eol の読み方

改行コードの状態を一覧できるコマンドです。直す前の調査と、直した後の確認の両方に使います。

i/lf    w/crlf  attr/text=auto eol=lf   src/app.js

リポジトリに CRLF や混在が入っているファイルだけを抜き出すには、grep と組み合わせます。

git ls-files --eol | grep -E '^i/(crlf|mixed)'

属性がどう解釈されたかは git check-attr で確かめられます。

git check-attr text eol -- src/app.js scripts/build.bat logo.png

src/app.js: text: auto
src/app.js: eol: lf
scripts/build.bat: text: set
scripts/build.bat: eol: crlf
logo.png: text: unset
logo.png: eol: lf

logo.png には eol: lf も表示されていますが、text が unset（-text）なので変換は行われません。

.gitattributes の書き方

属性の一覧

書き方のきまりは次のとおりです。

• 1行に「パターン 属性 属性 ...」を書きます。パターンの書き方は .gitignore とほぼ同じです。
• 同じファイルに複数の行が当てはまるときは、後ろの行が優先されます。全体の既定を先頭に、個別の指定を後ろに書きます。
• eol を書くと、text を書かなくてもテキストとして扱われます（公式ドキュメントの記述どおり、eol=lf だけの行も text eol=lf と同じ結果になりました）。

eol なしの text=auto は OS の既定に従う

* text=auto だけを書き、core.autocrlf=false にしたうえで core.eol を切り替えた結果です。

core.eol の既定は native（OS に合わせる）で、Windows では CRLF になります。公式ドキュメントにも「text が設定されていて autocrlf も core.eol も設定されていない場合、Windows では eol=crlf、それ以外では eol=lf が既定」と書かれています。全員の手元を同じ改行にしたいなら、eol=lf まで書くのが確実です。

コピペ用 .gitattributes ひな形

リポジトリの一番上に置きます。

# 既定: テキストと判定したものは LF で保存し、作業ツリーも LF
* text=auto eol=lf

# Windows 専用のスクリプトは CRLF で取り出す
*.bat  text eol=crlf
*.cmd  text eol=crlf
*.ps1  text eol=crlf

# シェルスクリプトは必ず LF
*.sh   text eol=lf

# バイナリは変換しない
*.png  binary
*.jpg  binary
*.pdf  binary
*.zip  binary

このひな形で、属性が意図どおりに付くことを確かめました。

git check-attr text eol diff -- a.sh b.bat c.png d.md

a.sh: text: set
a.sh: eol: lf
a.sh: diff: unspecified
b.bat: text: set
b.bat: eol: crlf
b.bat: diff: unspecified
c.png: text: unset
c.png: eol: lf
c.png: diff: unset
d.md: text: auto
d.md: eol: lf
d.md: diff: unspecified

手元も Windows の改行で扱いたいチーム向けには、1行目を次のように変えます。

# リポジトリは LF、作業ツリーは各自の OS に合わせる
* text=auto

既存リポジトリを git add --renormalize で直す

すでに CRLF が混ざったリポジトリを、LF にそろえる手順です。.gitattributes を追加しただけでは、すでにコミットされているファイルの中身は変わりません。 git add --renormalize で、現在の設定に合わせて入れ直します。

手順1：現状を調べる

CRLF・混在・LF・バイナリが混ざったリポジトリを用意しました（core.autocrlf=false）。

git ls-files --eol

i/-text w/-text attr/                   logo.png
i/crlf  w/crlf  attr/                   scripts/build.bat
i/crlf  w/crlf  attr/                   scripts/build.sh
i/crlf  w/crlf  attr/                   src/app.js
i/mixed w/mixed attr/                   src/mixed.md
i/lf    w/lf    attr/                   src/style.css

リポジトリ側（i/）に crlf が3つ、mixed が1つあります。

手順2：.gitattributes を置く

cat .gitattributes
git status --short

* text=auto eol=lf
*.bat text eol=crlf
*.png binary
 M scripts/build.bat
?? .gitattributes

.gitattributes を置いただけで、build.bat が「変更あり」と表示されました。属性が付いたことで、「リポジトリ側は LF であるべきなのに CRLF が入っている」と Git が判断したためです。ほかのファイルは、次の手順で入れ直すまで変化がありません。

手順3：renormalize を実行する

作業ツリーに未コミットの変更がない状態で実行します。

git add --renormalize .
git status --short
git diff --cached --stat

M  scripts/build.bat
M  scripts/build.sh
M  src/app.js
M  src/mixed.md
?? .gitattributes
 scripts/build.bat | 4 ++--
 scripts/build.sh  | 4 ++--
 src/app.js        | 4 ++--
 src/mixed.md      | 2 +-
 4 files changed, 7 insertions(+), 7 deletions(-)

CRLF が入っていた4ファイルだけがステージされました。もともと LF だった style.css とバイナリの logo.png は対象になっていません。

手順4：コミットして確認する

git add .gitattributes
git commit -m "Normalize line endings"
git ls-files --eol

i/lf    w/lf    attr/text=auto eol=lf   .gitattributes
i/-text w/-text attr/-text              logo.png
i/lf    w/crlf  attr/text eol=crlf      scripts/build.bat
i/lf    w/crlf  attr/text=auto eol=lf   scripts/build.sh
i/lf    w/crlf  attr/text=auto eol=lf   src/app.js
i/lf    w/mixed attr/text=auto eol=lf   src/mixed.md
i/lf    w/lf    attr/text=auto eol=lf   src/style.css

リポジトリ側（i/）はすべて LF になりました。一方、作業ツリー側（w/）にはまだ CRLF が残っています。renormalize が書き換えるのはインデックスだけで、手元のファイルはそのままだからです。

手順5：作業ツリーを取り出し直す

git rm -q --cached -r .
git reset -q --hard
git ls-files --eol

i/lf    w/lf    attr/text=auto eol=lf   .gitattributes
i/-text w/-text attr/-text              logo.png
i/lf    w/crlf  attr/text eol=crlf      scripts/build.bat
i/lf    w/lf    attr/text=auto eol=lf   scripts/build.sh
i/lf    w/lf    attr/text=auto eol=lf   src/app.js
i/lf    w/lf    attr/text=auto eol=lf   src/mixed.md
i/lf    w/lf    attr/text=auto eol=lf   src/style.css

作業ツリーも、build.bat だけ CRLF、ほかは LF という .gitattributes どおりの状態になりました。git reset --hard は未コミットの変更を取り消すコマンドなので、必ずコミット済みの状態で実行してください。新しくクローンし直す方法でも同じ結果になります。

text=auto はコミット済みの CRLF をそのまま保つ

text=auto には「すでに CRLF でコミットされているファイルは変換しない」というきまりがあります。確かめた結果です。

# old.txt は CRLF でコミット済み。.gitattributes に "* text=auto" を追加後、
# old.txt を編集し、new.txt（CRLF）を新しく作って git add
git add . ; git ls-files --eol

warning: in the working copy of 'new.txt', CRLF will be replaced by LF the next time Git touches it
i/lf    w/lf    attr/text=auto          .gitattributes
i/lf    w/crlf  attr/text=auto          new.txt
i/crlf  w/crlf  attr/text=auto          old.txt

新しい new.txt は LF に変換されましたが、コミット済みだった old.txt は、編集して add しても CRLF のままです。ここで renormalize を実行すると LF にそろいます。

git add --renormalize . ; git ls-files --eol

i/lf    w/lf    attr/text=auto          .gitattributes
i/lf    w/crlf  attr/text=auto          new.txt
i/lf    w/crlf  attr/text=auto          old.txt

「.gitattributes を入れたのに直らない」と感じたときは、このきまりが働いています。導入のときに一度 renormalize する、と覚えておくとすっきりします。

直した後の差分と blame の見え方

改行だけを直したコミットは、行数ぶんの変更として記録されます。レビューや履歴の調査では、次のオプションが役立ちます。

git diff HEAD~1 --stat -- src/app.js
git diff HEAD~1 --stat --ignore-cr-at-eol -- src/app.js

 src/app.js | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--ignore-cr-at-eol を付けた2つ目は何も表示されず、改行以外の変更がないことを確かめられます。

git blame は、そのままだと全行が「Normalize line endings」のコミットを指しますが、-w を付けると元のコミットをたどれました。

renormalize の手順まとめ

改行の修正は、機能の変更と分けて単独のコミットにすると、あとから差分を読みやすくなります。ほかの人が作業中のブランチとは、この修正を取り込んだあとに改行の差で競合が出ることがあるので、実施のタイミングをチームで共有しておくとスムーズです。

Windows・WSL2・macOS 別の推奨設定

この節の OS 別の設定は、Windows・macOS の実機では未実行です。上の早見表（Linux 上で設定を切り替えて確認した結果）と公式ドキュメントの記述をもとに整理しています。

リポジトリに .gitattributes がある場合（おすすめ）

* text=auto eol=lf のように eol まで書いてあれば、個人の autocrlf の値に関係なく同じ結果になります。早見表のとおり、true・input・false のどれでも、リポジトリ LF・作業ツリー LF でした。

リポジトリに .gitattributes がない場合

どの環境でも コミット時に CRLF が LF になる設定なので、リポジトリには LF だけが入ります。

WSL2 を使うときのポイント

• WSL2 の中の Git と Windows 側の Git は、設定ファイルが別々です。それぞれで git config --global を設定します。
• 同じ作業ツリーを Windows 側の Git（autocrlf=true）と WSL2 側の Git（autocrlf=input）の両方から操作すると、手元の改行の解釈が変わり、変更していないファイルに差分が出ることがあります。どちらか一方の Git で操作すると決めておくと安定します。
• eol=lf を書いた .gitattributes があれば、どちらの Git から操作しても作業ツリーは LF になります。

エディタ側もそろえる

Git の設定に加えて、エディタが新しいファイルを作るときの改行もそろえておくと、警告を見る機会が減ります。EditorConfig に対応したエディタなら、リポジトリに次のファイルを置く方法があります（エディタの動作は未実行です）。

# .editorconfig
root = true

[*]
end_of_line = lf
insert_final_newline = true

[*.{bat,cmd,ps1}]
end_of_line = crlf

改行コードが原因のエラーと直し方

シェルスクリプトが起動しない

1行目（シバン）の末尾に CR が付いていると、インタープリタの名前が /bin/bash\r と解釈されます。

printf '#!/bin/bash\r\necho hi\r\n' > x.sh
chmod +x x.sh
./x.sh

./x.sh: cannot execute: required file not found

ファイル自体は存在するのに「required file not found」と表示されるのが特徴です（bash 5.2 での表示。行頭には呼び出し元の名前と行番号が付きます）。

CR が入っているかを調べて取り除く

file f.txt
grep -c $'\r' f.txt
sed -i "s/\r$//" f.txt
file f.txt

f.txt: ASCII text, with CRLF line terminators
2
f.txt: ASCII text

file コマンドは「with CRLF line terminators」と表示し、grep -c $'\r' は CR を含む行数を返します。sed -i "s/\r$//" で行末の CR を取り除けます。根本的には、*.sh text eol=lf を .gitattributes に書いておくと、どの OS でチェックアウトしても LF になります。

症状から引く対応表

よくある質問

Q. autocrlf と .gitattributes は、どちらが優先されますか？ A. .gitattributes に eol=lf や eol=crlf、-text が書かれているファイルは、autocrlf の値に関係なくその指定どおりになります。本文の早見表のとおり、true・input・false のすべてで同じ結果でした。text=auto だけで eol がない場合は、作業ツリーの改行が autocrlf と core.eol、OS の既定で決まります。

Q. 「LF will be replaced by CRLF」は直さないといけませんか？ A. エラーではなく、次のチェックアウトで手元のファイルが CRLF になることを知らせる表示です。git add は完了していて、リポジトリには LF で入ります。手元も LF のままにしたい場合は、.gitattributes に * text=auto eol=lf を書くと表示されなくなります。

Q. git add --renormalize を実行すると、履歴はどうなりますか？ A. 過去のコミットは書き換わりません。現在のファイルを LF に入れ直す新しいコミットが1つ増えます。改行だけの差分は git diff --ignore-cr-at-eol で除外でき、git blame -w で元のコミットをたどれます。

Q. core.autocrlf は false にしておくほうがよいですか？ A. リポジトリに eol つきの .gitattributes があるなら、false でも結果は同じです。.gitattributes がないリポジトリで false にすると変換が一切行われないので、CRLF がそのままコミットされます。その場合は Windows なら true、macOS・Linux・WSL2 なら input が扱いやすい設定です。

まとめ

• autocrlf は個人の設定、.gitattributes はリポジトリで共有する設定。eol を書いた .gitattributes は autocrlf より優先される
• * text=auto eol=lf を書くと、autocrlf が true・input・false のどれでもリポジトリ LF・作業ツリー LF になる
• 「LF will be replaced by CRLF」はエラーではなく、次のチェックアウトで手元が CRLF になるというお知らせ
• git ls-files --eol の i/ はリポジトリ、w/ は作業ツリー、attr/ は効いている属性
• 既存リポジトリは git add --renormalize . で入れ直す。text=auto はコミット済みの CRLF を保つため、導入時に一度実行する
• renormalize のあと、作業ツリーは取り出し直すまで元の改行のまま
• .bat は eol=crlf、.sh は eol=lf、画像は binary と個別に指定する

株式会社RJCでは、Gitの設定やチーム開発での使い方を仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。