VSCodeでファイルを編集していると、意図していないのに改行コードがLFからCRLFへ変わったり、反対にCRLFからLFへ変わったりすることがあります。
原因はVSCode本体だけとは限りません。
Gitの設定や.gitattributes、.editorconfig、フォーマッター、OSの違いなど、複数の要素が改行コードに影響する可能性があります。
特にWindowsとLinux、macOSが混在する開発環境では、改行コードの違いによってGit上でファイル全体が変更扱いになることもあります。
問題が発生した場合は、どの設定が改行コードを制御しているのかを順番に確認することが重要です。
VSCodeで使われる改行コードとは
LFとCRLFの違い
代表的な改行コードには、LFとCRLFがあります。
LFは\nで表され、LinuxやmacOSで一般的に使われます。
一方、CRLFは\r\nで表され、Windowsで一般的に使われます。
主な違いは次のとおりです。
| 改行コード | 表記 | 主に使われる環境 |
|---|---|---|
| LF | \n | Linux、macOS |
| CRLF | \r\n | Windows |
Web開発では、Windows環境で開発している場合でも、ソースコードをLFに統一する運用が採用されることがあります。
VSCodeで現在の改行コードを確認する方法
VSCodeでは、現在開いているファイルの改行コードを画面右下のステータスバーで確認できます。
LFのファイルであれば「LF」、CRLFのファイルであれば「CRLF」と表示されます。
この表示をクリックすると、現在のファイルの改行コードを変更できます。
原因1：VSCodeのfiles.eol設定が影響している
files.eolとは
VSCodeには、改行コードに関するfiles.eolという設定があります。
たとえばLFを使用したい場合は、settings.jsonに次のように設定できます。
{
"files.eol": "\n"
}
CRLFを使用したい場合は、次のようにします。
{
"files.eol": "\r\n"
}
OSに応じたデフォルト動作を利用したい場合は、次の設定を使用できます。
{
"files.eol": "auto"
}
files.eolを変更しても既存ファイルは自動変換されない
注意したいのは、files.eolを変更したからといって、すでに存在するファイルの改行コードがすべて自動的に変換されるわけではないことです。
たとえば既存ファイルがCRLFで保存されている場合に、
{
"files.eol": "\n"
}
と設定しても、そのファイルがただちにLFへ変換されるわけではありません。
既存ファイルを変更したい場合は、VSCodeの「Change End of Line Sequence」を使って個別に変換します。
そのため、files.eolをLFに設定しているにもかかわらず既存ファイルがCRLFになっていても、それだけで設定が間違っているとは限りません。
原因2：Gitのcore.autocrlfで改行コードが変換されている
core.autocrlfを確認する
VSCodeで改行コードが意図せず変わる場合、Gitのcore.autocrlfが原因になっていることがあります。
現在のグローバル設定は、次のコマンドで確認できます。
git config --global core.autocrlf
リポジトリ単位の設定を確認する場合は、次のコマンドを使用します。
git config --local core.autocrlf
どの設定ファイルから値が読み込まれているのかまで確認したい場合は、次のコマンドが便利です。
git config --show-origin --get core.autocrlf
core.autocrlf=trueの場合
Windows環境では、次のように設定されていることがあります。
git config --global core.autocrlf true
この設定では、Gitがテキストファイルとして扱うファイルについて、リポジトリ内ではLFへ正規化しつつ、作業ツリーではCRLFへ変換されることがあります。
ただし、.gitattributesでeol=lfなどが指定されている場合は、そちらの設定も影響します。
そのため、「GitHub上ではLFなのに、Windowsでcloneしたファイルを見るとCRLFになっている」という場合は、VSCodeではなくGitの設定が原因である可能性があります。
core.autocrlf=inputの場合
次の設定では、主にコミット時にCRLFからLFへ正規化されます。
git config --global core.autocrlf input
一方で、checkout時にLFからCRLFへ変換する動作は行われません。
LinuxやmacOS環境で利用されることのある設定です。
core.autocrlf=falseの場合
次のように設定すると、core.autocrlfによる自動変換は行われません。
git config --global core.autocrlf false
ただし、.gitattributesなど別のルールが設定されている場合は、改行コードが制御されることがあります。
そのため、core.autocrlf=falseにしても改行コードが変化する場合は、.gitattributesも確認しましょう。
参考サイト
VS Codeの改行コード設定が効かずにどハマりした話 #Git – Qiita
原因3：.gitattributesで改行コードが指定されている
.gitattributesとは
.gitattributesは、Gitでファイルの扱い方を指定できる設定ファイルです。
チーム開発では、各開発者のGit設定に依存せず、リポジトリ単位で改行コードを統一する目的でも利用されます。
たとえば、次の設定があります。
* text=auto
この場合、Gitがテキストファイルと判断したファイルについて、改行コードの正規化が行われます。
LFに統一する場合
テキストファイルを基本的にLFで扱いたい場合は、次のように設定できます。
* text=auto eol=lf
また、ファイルの種類ごとに設定することもできます。
* text=auto
*.js text eol=lf
*.ts text eol=lf
*.css text eol=lf
*.html text eol=lf
*.sh text eol=lf
*.bat text eol=crlf
*.cmd text eol=crlf
この方法であれば、Web系のソースコードやシェルスクリプトはLF、Windows用のバッチファイルはCRLFといった運用ができます。
.gitattributesとcore.autocrlfの両方を確認する
改行コードの問題を調査するときは、core.autocrlfだけで判断しないことが重要です。
.gitattributesでファイルごとの改行コードが指定されている場合、Gitのグローバル設定だけを見ても実際の挙動を判断できないことがあります。
特にチーム開発では、.gitattributesがプロジェクト側のルールとして使用されているケースが多いため、必ず確認しておきましょう。
原因4：.editorconfigで改行コードが指定されている
end_of_lineを確認する
プロジェクト内に.editorconfigがある場合は、end_of_lineの設定を確認します。
たとえば、次のように設定されている場合があります。
[*]
end_of_line = lf
CRLFを使う場合は、次のように指定します。
[*]
end_of_line = crlf
.editorconfigでは、LF、CRLF、CRといった改行コードを指定できます。
プロジェクト全体の編集ルールとして使われる
たとえばWeb開発では、次のような設定が使われることがあります。
root = true
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
indent_style = space
indent_size = 2
このような設定があると、改行コードだけでなく、文字コードやインデントなどの編集ルールもプロジェクト内で統一しやすくなります。
ただし、.editorconfigの設定がどのように適用されるかは、使用しているエディターや拡張機能の対応状況にも関係します。
そのため、「.editorconfigが必ずVSCodeのすべての設定より優先される」と単純に考えるのではなく、改行コードへ影響する設定のひとつとして確認するのが適切です。
原因5：ユーザー設定とワークスペース設定が異なっている
.vscode/settings.jsonを確認する
VSCodeには、ユーザー全体へ適用される設定だけでなく、プロジェクト単位のワークスペース設定もあります。
たとえばユーザー設定では、
{
"files.eol": "\n"
}
となっていても、プロジェクト内の.vscode/settings.jsonに、
{
"files.eol": "\r\n"
}
と設定されている場合があります。
このような場合、開いているプロジェクトによって改行コードに関する挙動が変わることがあります。
言語別設定にも注意する
VSCodeでは、言語別に設定を変更することもできます。
たとえば次のような設定です。
{
"[shellscript]": {
"files.eol": "\n"
}
}
特定の言語だけ改行コードの挙動が異なる場合は、言語別設定も確認してみましょう。
原因6：フォーマッターや拡張機能が保存時に変更している
formatOnSaveを確認する
VSCodeでは、保存時に自動フォーマットを実行できます。
たとえば次の設定です。
{
"editor.formatOnSave": true
}
ただし、editor.formatOnSave自体が直接改行コードを変換するわけではありません。
実際に改行コードが変わるかどうかは、使用しているフォーマッターや拡張機能の設定に依存します。
たとえば、Prettierや各言語向けフォーマッターなどに独自の改行コード設定がある場合、保存時にファイルが書き換えられる可能性があります。
保存時だけ改行コードが変わる場合の確認方法
「ファイルを開いた時点では問題ないのに、Ctrl+Sを押した直後にLFからCRLFへ変わる」といった場合は、保存時処理を疑ってみましょう。
一時的に次の設定へ変更して確認できます。
{
"editor.formatOnSave": false
}
この状態で保存して改行コードが変わらなくなった場合は、フォーマッターや保存時アクションが原因である可能性があります。
原因7：Windows・WSL・Docker・Linuxをまたいで編集している
異なるOSでは一般的な改行コードが異なる
WindowsではCRLF、LinuxやmacOSではLFが一般的です。
そのため、次のような環境を組み合わせて開発している場合は注意が必要です。
Windows
↓
WSL
↓
Docker
↓
Linuxサーバー
Windows側とLinux側の両方から同じファイルを操作すると、設定によっては改行コードが変わることがあります。
シェルスクリプトは特に注意する
Linux上で実行するシェルスクリプトがCRLFになっていると、実行時に問題が発生することがあります。
たとえば、次のようなシェルスクリプトがあるとします。
#!/bin/bash
このファイルがCRLFになっていると、環境によっては次のようなエラーにつながることがあります。
/bin/bash^M: bad interpreter
WSLやDocker、Linuxサーバーを使うプロジェクトでは、シェルスクリプトをLFに統一しておくとトラブルを避けやすくなります。
原因8：ファイル内でLFとCRLFが混在している
コピー＆ペーストなどで混在することがある
1つのファイル内にLFとCRLFが混在するケースもあります。
たとえば、一部の行だけ別のOSやエディターからコピー＆ペーストした場合などです。
1行目：LF
2行目：LF
3行目：CRLF
4行目：LF
このような状態では、Gitの差分が分かりにくくなったり、ツールによって意図しない変換が行われたりする場合があります。
core.safecrlfで確認する
Gitには、改行コードの変換に問題がないか確認するためのcore.safecrlfという設定があります。
警告を表示させる場合は、次のように設定できます。
git config --global core.safecrlf warn
問題のある変換を拒否したい場合は、次のようにします。
git config --global core.safecrlf true
ただし、この設定は単純に「LFとCRLFの混在を探すための専用機能」というより、Gitによる改行コード変換が安全に行えるかを確認するためのものです。
VSCodeで改行コードを変更する方法
現在開いているファイルをLFに変更する
現在のファイルだけ改行コードを変更したい場合は、VSCodeの画面右下に表示されている「LF」または「CRLF」をクリックします。
すると「Change End of Line Sequence」を選択できるので、LFにしたい場合は「LF」を選びます。
その後、ファイルを保存します。
CRLFへ変更したい場合は「CRLF」を選択します。
コマンドパレットから「Change End of Line Sequence」を実行することもできます。
VSCodeのデフォルトをLFにする
新しく扱うファイルでLFを基本にしたい場合は、settings.jsonに次の設定を追加します。
{
"files.eol": "\n"
}
VSCodeの設定画面から変更する場合は、「Files: Eol」を検索して設定できます。
ただし、この設定だけで既存ファイルがすべてLFへ自動変換されるわけではありません。
Git管理しているプロジェクトでLFに統一する方法
.gitattributesを設定する
チーム開発では、各メンバーのVSCode設定だけに頼るよりも、リポジトリ側で改行コードのルールを決めるほうが管理しやすくなります。
たとえば、基本的にLFを使う場合は次のように設定できます。
* text=auto eol=lf
*.bat text eol=crlf
*.cmd text eol=crlf
これにより、テキストファイルは基本的にLFとしながら、Windows用のバッチファイルだけCRLFにすることができます。
.editorconfigも併用する
さらに、.editorconfigにも次のように設定しておくと、エディター側の編集ルールも統一しやすくなります。
root = true
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
.gitattributesはGit側の管理、.editorconfigはエディター側の編集ルールという形で、役割を分けて考えると分かりやすいでしょう。
既存ファイルをまとめて再正規化する方法
git add –renormalizeを利用する
すでに多くのファイルがGit管理されている状態で.gitattributesを追加した場合、既存ファイルにも新しい改行コードのルールを反映させたいことがあります。
その場合は、次のコマンドを使用できます。
git add --renormalize .
たとえば、.gitattributesへ次のような設定を追加します。
* text=auto eol=lf
その後に、
git add --renormalize .
を実行します。
続いて、
git status
や、
git diff --cached
などで変更内容を確認します。
大量のファイルが変更扱いになる可能性があるため、実行前後の差分確認は重要です。
また、機能修正と改行コードの正規化を同じコミットに含めると履歴が追いにくくなるため、改行コードの変更だけを別コミットに分けると管理しやすくなります。
Gitでファイル全体が変更扱いになる場合の確認方法
1行しか編集していないのに全行変更になることがある
コードを1行しか修正していないにもかかわらず、Git上では数百行、数千行が変更扱いになる場合があります。
この場合、改行コードがLFからCRLF、またはCRLFからLFへ変わっている可能性があります。
まず、VSCode右下の表示で現在の改行コードを確認します。
その後、次のコマンドでGitの差分を確認します。
git diff
さらに、Gitの改行コード設定を確認します。
git config --show-origin --get core.autocrlf
加えて、次のファイルも確認しましょう。
.gitattributes
.editorconfig
.vscode/settings.json
これらを確認すると、どの設定によって改行コードが変わっているのかを特定しやすくなります。
改行コードが勝手に変わるときの確認手順
まず確認したいポイント
改行コードの問題が起きた場合は、次の順番で確認すると原因を切り分けやすくなります。
- VSCode右下で「LF」または「CRLF」を確認する
settings.jsonのfiles.eolを確認する.vscode/settings.jsonを確認する.editorconfigのend_of_lineを確認する.gitattributesのeol指定を確認するgit config --show-origin --get core.autocrlfを確認する- 保存時フォーマッターを一時的に無効化する
- WSLやDocker、Linux側でファイルが書き換えられていないか確認する
特に重要なのは、VSCodeだけではなく、Gitやプロジェクト設定も含めて調査することです。
Web開発でおすすめの改行コード設定
基本的にLFへ統一する場合
Windows、macOS、Linuxの開発者が混在するWeb開発では、ソースコードをLFへ統一すると管理しやすいケースが多くあります。
VSCodeでは、次のように設定できます。
{
"files.eol": "\n"
}
.editorconfigでは、次のように設定します。
root = true
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
.gitattributesでは、次のような設定が考えられます。
* text=auto eol=lf
*.bat text eol=crlf
*.cmd text eol=crlf
このように、VSCode、EditorConfig、Gitの設定をそろえておくと、環境による改行コードの違いを減らしやすくなります。
まとめ
VSCodeで改行コードが勝手に変わる場合、原因はVSCode本体だけとは限りません。
特に確認したいのは、files.eol、Gitのcore.autocrlf、.gitattributes、.editorconfig、フォーマッター、OS間の違いです。
VSCodeのfiles.eolだけを変更しても、Gitや.gitattributesなど別の設定が改行コードを制御していれば、問題が解消しないことがあります。
まずはVSCode右下の「LF」「CRLF」を確認し、続いて次のコマンドを実行すると原因を調査しやすくなります。
git config --show-origin --get core.autocrlf
そのうえで、.gitattributes、.editorconfig、.vscode/settings.jsonを確認しましょう。
チーム開発では、各メンバーの環境に任せるのではなく、.gitattributesや.editorconfigをリポジトリに含め、プロジェクト単位で改行コードのルールを統一しておくことが再発防止につながります。
以上、VSCodeで改行コードが勝手に変わる主な原因についてでした。
最後までお読みいただき、ありがとうございました。
