改行コードでつまずかないためのCRLF/LF入門：Git・WordPress・Linuxで見るポイント
改行コードは、見た目には同じ「改行」でも、ファイルの中では CRLF や LF という別の文字列として保存されています。
実務で大事なのは、Windowsで作ったファイルをLinuxサーバーやGitに渡すとき、改行コードの違いがエラーや差分の増加につながることです。WordPressのテーマ編集、シェルスクリプト、CSV処理、Git運用では、ここを知らないと原因が見えにくいトラブルになります。
この記事で分かることは次のとおりです。
CRLFとLFの違い- Windows、Linux、macOSで改行コードが問題になる場面
- Gitで改行コードをそろえる基本設定
- WordPressやサーバー運用で初心者が確認すべきポイント
- 変換方法、よくある失敗、代替手段
対象環境は、2026年7月時点の一般的な Windows / Linux / macOS、Git 2.55.0 の公式ドキュメント、EditorConfig の公式仕様を前提にしています。エディタやホスティング環境によって表示名や設定画面は変わりますが、考え方は共通です。
改行コードとは、行の終わりを表す見えない文字
改行コードは、テキストファイルで「ここで行が終わる」とコンピューターに伝えるための制御文字です。
文章として見ると、どちらもただの改行に見えます。しかし、ファイルの中身としては次のように違います。
| 表記 | 中身 | 主に使われる環境 | 実務での見え方 |
|---|---|---|---|
| LF | \n | Linux、macOS、Webサーバー、Gitリポジトリ内 | サーバー上のスクリプトや設定ファイルで標準的 |
| CRLF | \r\n | Windowsの古い慣習、Windows向けテキスト | Windowsのメモ帳や一部ツールで自然に作られることがある |
| CR | \r | 古いMac環境など | 現在の実務ではほとんど使わない |
CR は carriage return、LF は line feed の略です。歴史的な由来はありますが、実務では「Windows系はCRLFになりやすい」「LinuxサーバーではLFが無難」と覚えるほうが役に立ちます。
ここがポイント: ブラウザで見るHTMLやWordPress記事の本文では差が見えにくくても、Git、シェル、設定ファイル、データ処理では改行コードがそのまま問題になります。
CRLFとLFの違いが実務で効く場面
改行コードの違いは、ファイルを読む側が「どこまでを1行と見るか」に影響します。
Linuxサーバーのシェルスクリプト
一番分かりやすい例は、Windowsで作った deploy.sh をLinuxサーバーで実行する場面です。
入力例として、次のようなシェルスクリプトを考えます。
#!/bin/bash
echo "deploy start"
見た目は問題なくても、ファイルが CRLF で保存されていると、Linux側では1行目の末尾に \r が残ります。その結果、環境によっては次のようなエラーになります。
/bin/bash^M: bad interpreter: No such file or directory
^M は、画面上で見える形にされた CR です。つまり、Linuxは #!/bin/bash ではなく、余分な文字が付いたパスを読んでしまっています。
この場合、原因は権限やbashのインストールではなく、改行コードがCRLFのままサーバーへ渡ったことです。
Gitの差分が大量に出る
もう一つ多いのが、Gitで「何も編集していないはずのファイルが大量に変更扱いになる」ケースです。
たとえば、ある人の環境ではLF、別の人の環境ではCRLFに自動変換される設定になっていると、実際の修正は1行だけでも、Git上ではファイル全体が変わったように見えることがあります。
これはレビューを難しくします。
- 本当に直した行が見つけにくい
- Pull Requestの差分が読みにくい
- 自動整形やビルド設定の変更と混ざる
- 余計なコンフリクトが起きる
Git公式の gitattributes ドキュメントでは、テキストファイルをリポジトリ内ではLFに正規化し、作業ツリーでは設定に応じて変換できる仕組みが説明されています。チームで扱うなら、個人のエディタ任せにせず、リポジトリ側にルールを置くのが現実的です。
WordPressテーマや設定ファイル
WordPressのPHP、CSS、JavaScript、HTMLでは、改行コードが違うだけで常に壊れるわけではありません。多くの場合、PHPやブラウザはCRLFでもLFでも読みます。
ただし、WordPress周辺では次のファイルで注意が必要です。
- デプロイ用の
.shファイル - DockerやCIで実行するスクリプト
.htaccessやサーバー設定に近いファイル- CSVインポート用のデータ
- Git管理しているテーマやプラグインのソース
特に、Windowsで編集してLinuxサーバーにアップロードする流れでは、表示上の違いがないまま問題が混ざります。WordPress本体というより、周辺の運用ファイルで効いてくると考えると分かりやすいです。
まず確認するコマンドと見方
改行コードのトラブルでは、推測より先にファイルの状態を確認します。
Git管理下なら git ls-files --eol
Gitリポジトリ内では、次のコマンドが便利です。
git ls-files --eol
出力例です。
i/lf w/lf attr/text=auto scripts/deploy.sh
i/lf w/crlf attr/text=auto docs/sample.txt
見方は次のとおりです。
i/lf: Gitのインデックス内ではLFw/lf: 作業中のファイルもLFw/crlf: 作業中のファイルはCRLFattr/text=auto:.gitattributesなどで自動判定対象
ここで見るべきなのは、サーバーで実行するファイルが w/crlf になっていないかです。たとえば scripts/deploy.sh、*.sh、CI用の設定に近いファイルはLFでそろえるほうが扱いやすくなります。
LinuxやmacOSなら file と cat -v
Git管理外のファイルなら、まず file コマンドで確認できます。
file deploy.sh
出力例です。
deploy.sh: Bourne-Again shell script, ASCII text executable, with CRLF line terminators
with CRLF line terminators と出ていれば、CRLFです。
さらに目で確認したい場合は、次のようにします。
cat -v deploy.sh
CRLFのファイルでは、行末に ^M が見えることがあります。
#!/bin/bash^M
echo "deploy start"^M
この ^M が見えたら、Linuxサーバーで実行するスクリプトとしては変換対象です。
Gitで改行コードをそろえる基本設定
チームや複数PCで作業するなら、Gitの設定を個人任せにしないことが重要です。
.gitattributes でリポジトリのルールを決める
Git公式ドキュメントでは、.gitattributes によってパスごとの属性を定義できます。改行コードでは text と eol がよく使われます。
Web制作やWordPressテーマで使いやすい最小例は次の形です。
* text=auto
*.sh text eol=lf
*.php text eol=lf
*.css text eol=lf
*.js text eol=lf
*.html text eol=lf
*.json text eol=lf
*.yml text eol=lf
*.yaml text eol=lf
*.bat text eol=crlf
*.cmd text eol=crlf
*.ps1 text eol=crlf
この例では、通常のテキストファイルは自動判定しつつ、LinuxサーバーやWeb系で使うファイルはLFに寄せています。一方で、WindowsのバッチファイルはCRLFにしています。
注意点は、すでにGit管理されているファイルには、設定を追加しただけでは期待どおり反映されないことがある点です。Git公式ドキュメントでは、正規化を導入する流れとして git add --renormalize . が紹介されています。
git add --renormalize .
git status
この操作は差分が大きく出ることがあります。実務では、機能改修とは別のコミットに分けるほうがレビューしやすくなります。
core.autocrlf は個人環境の設定
Gitには core.autocrlf という設定もあります。
git config --global core.autocrlf true
Windows環境で見かける設定ですが、これは基本的に個人のGit設定です。チーム全体のルールとしては、.gitattributes のほうが明示的です。
目安としては次のように考えると整理しやすいです。
- 個人PCの都合:
core.autocrlf - リポジトリ全体の約束:
.gitattributes - エディタの保存ルール:
.editorconfig
core.autocrlf だけに頼ると、メンバーごとの差が残ります。特にWordPressテーマ、Docker、CI、サーバー用スクリプトを含むリポジトリでは、.gitattributes を入れておく価値があります。
エディタではEditorConfigで保存時のズレを減らす
Gitの変換だけでなく、エディタで保存する時点のルールもそろえると、トラブルが減ります。
EditorConfigは、複数のエディタやIDEで共通のコーディングスタイルを扱うための設定ファイルです。公式サイトでは、改行コードを指定する end_of_line、末尾改行を指定する insert_final_newline などが定義されています。
WordPressやWeb制作向けの例です。
root = true
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true
indent_style = space
indent_size = 2
[*.md]
trim_trailing_whitespace = false
[*.{bat,cmd,ps1}]
end_of_line = crlf
ここでは、基本はLFにしつつ、Windows向けのスクリプトだけCRLFにしています。
trim_trailing_whitespace = true は行末の余分な空白を消す設定です。ただしMarkdownでは、行末スペースを意図的に改行表現として使う場合があります。そのため、上の例では *.md だけ例外にしています。
Gitはリポジトリへの入り口、EditorConfigは保存時の入り口です。両方を使うと、混入を早い段階で止めやすくなります。
変換方法：CRLFをLFに直す最小例
すでにCRLFになっているファイルは、エディタやコマンドで変換できます。
VS Codeなどのエディタで直す
多くのエディタでは、画面下部や設定画面に CRLF / LF の表示があります。
基本手順は次の流れです。
- 対象ファイルを開く
- 改行コード表示で
CRLFかLFを確認する - Linuxサーバー用なら
LFに変更する - 保存する
- Git差分を確認する
初心者には、この方法が一番安全です。1ファイルずつ確認できるため、バイナリファイルや意図しないファイルまで変換しにくいからです。
コマンドで直す
LinuxやmacOS、WSLでは、perl を使ってCRLFをLFへ変換できます。
perl -pi -e 's/\r\n/\n/g' deploy.sh
変換後に確認します。
file deploy.sh
cat -v deploy.sh
期待する状態は、file の出力に with CRLF line terminators が出ず、cat -v でも行末に ^M が出ないことです。
複数ファイルをまとめて変換する場合は、対象を絞ります。たとえばシェルスクリプトだけなら次のようにします。
find scripts -name "*.sh" -type f -print0 | xargs -0 perl -pi -e 's/\r\n/\n/g'
ここで大事なのは、リポジトリ全体に対して無差別に変換しないことです。画像、PDF、zipなどのバイナリファイルは対象外にします。
よくある失敗と対処
改行コードの問題は、エラー文だけでは分かりにくいことがあります。よくある形で整理します。
bad interpreter が出る
LinuxサーバーやDocker内で .sh を実行したときに、次のようなエラーが出るケースです。
/bin/bash^M: bad interpreter: No such file or directory
確認する順番は次のとおりです。
cat -v script.shで^Mが出るか見るfile script.shでCRLF表示があるか見る- LFに変換する
- 実行権限も必要なら
chmod +x script.shを確認する
権限エラーと改行コードエラーは混同しやすいですが、^M が出ているなら先に改行コードを直します。
Git差分がファイル全体に広がる
改行コードだけが変わると、Gitの差分が読みにくくなります。
対処は、機能修正と改行コードの正規化を分けることです。
- 先に
.gitattributesを追加する git add --renormalize .で正規化する- 正規化だけの差分として確認する
- その後に機能修正を行う
すでに作業中の変更がある場合は、先に現在の差分を退避するか、改行コード変換の対象ファイルを最小限にします。混ぜると、レビューする人が実質的な変更を追えなくなります。
CSVやテキスト処理で行数が合わない
CSVやログを処理するとき、改行コードの違いが末尾の \r として残ることがあります。
たとえば、Linux上でCRLFのCSVを単純に読むと、最後の列に \r が付く場合があります。
入力例です。
id,name
1,Alice
2,Bob
雑に行を分割すると、次のような値になります。
Bob\r
Pythonなら、標準の csv モジュールを使い、ファイルを開くときに newline='' を指定するのが基本です。
import csv
with open("users.csv", newline="", encoding="utf-8") as f:
reader = csv.DictReader(f)
for row in reader:
print(row["id"], row["name"])
期待される出力です。
1 Alice
2 Bob
CSVは自分で split(',') して処理すると、改行コード、引用符、カンマ入り文字列で壊れやすくなります。改行コードだけの問題に見えても、実務ではCSVパーサーを使うほうが安全です。
どの改行コードを選ぶべきか
結論として、Web制作、WordPressテーマ、Linuxサーバー、Git管理のソースコードでは、基本をLFに寄せるのが扱いやすいです。
ただし、すべてをLFにすればよいわけではありません。Windows専用のバッチファイルや、受け渡し先のツールがCRLFを前提にしているファイルでは、CRLFを使う理由があります。
判断の目安は次のとおりです。
- Linuxサーバーで実行する
.sh: LF - PHP、CSS、JS、HTML、JSON、YAML: LFを基本にする
- Gitリポジトリ内の通常のテキスト: LFに正規化する
- Windowsの
.bat/.cmd: CRLF - PowerShellスクリプト: チームや実行環境のルールに合わせる
- 外部ツールに渡すCSV: 相手の仕様を確認する
実務で見落とされやすいのは、改行コードを「OSの好み」だけで決めてしまうことです。実際には、そのファイルを最後に読むプログラムやサーバーが何を期待しているかで決めます。
最小チェックリスト
改行コードでつまずいたら、次の順に確認すると原因を絞りやすくなります。
- Linuxサーバーで実行するファイルが
CRLFになっていないか cat -vで行末に^Mが出ていないか- Git管理下なら
git ls-files --eolで状態を見たか .gitattributesでリポジトリのルールを決めているか.editorconfigでエディタ保存時のルールを決めているか- 機能変更と改行コード変換を同じ差分に混ぜていないか
- CSVなどのデータ処理では専用パーサーを使っているか
改行コードは、普段は見えません。だからこそ、エラーが出てから手作業で直すより、Gitとエディタの入口でそろえるほうが安定します。
次に見るべきポイントは、自分のプロジェクトに .gitattributes と .editorconfig があるかです。なければ、まずシェルスクリプトとWeb系ファイルだけでもLFに固定するところから始めると、WindowsとLinuxをまたぐ作業の失敗を減らせます。