【Git】autocrlfとは？異なるOS間の改行コード問題をわかりやすく解説

Web開発•2025/2/21

はじめに

Gitはバージョン管理システムとして多くのプロジェクトで使われています。
しかし、開発者が使用するOSによっては、改行コードの違いによる混乱が生じることがあります。
Windows環境ではCRLF、LinuxやmacOS環境ではLFが一般的に使われているため、ファイルを共有するときに意図せず改行コードが書き換わる現象が発生しがちです。

この現象を対処する方法として知られているのが、git autocrlf という設定です。
複数の開発者が共同作業をするプロジェクトでも、改行コードの差異を最小限に抑え、不要な差分が発生しないようにするために重要な機能となります。
ここでは、初心者の方にもわかりやすいように、改行コードの基本からgit autocrlfの使い方まで、実務に絡めて解説していきます。

この記事を読むとわかること

改行コードの仕組みとOSごとの違い
git autocrlfが果たす役割
true・input・falseなどの具体的な設定方法
実際のチーム開発における活用シーンと注意点
よくあるトラブル事例と対策方法

git autocrlf とは

Gitには、チェックアウトやコミット時の改行コードを自動的に変換する仕組みがあります。
これがcore.autocrlfと呼ばれる設定項目です。
具体的には、リポジトリからファイルを取り出すときや、ローカルで編集したファイルをコミットするときに、自動的に改行コードを変換してくれる機能を指します。

たとえば、Windows環境で作業している場合、テキストエディタによってはファイルを保存する際にCRLFで改行が入ることがあります。
一方、LinuxやmacOSの開発者はLFを使うことが多いでしょう。
もしこの差異を何も設定せずに共有してしまうと、Gitの履歴上では「改行コードが変わっただけ」の差分が延々と並んでしまうかもしれません。

この問題を避けるために、git autocrlfを正しく設定し、ローカルとリポジトリ間で改行コードを統一させることで、不要な差分の発生を抑えることができます。
初心者の方でも使いやすいように、設定値の種類や実際のコマンド例を後ほど紹介します。

WindowsとLinuxの改行コードの違い

Windowsは CRLF (\r\n) という2つの制御文字を使って改行を表現しています。一方でLinuxやmacOSでは、 LF (\n) のみで改行を示します。見た目はどちらも同じように改行されているように見えますが、内部的には異なる文字コードが含まれているのです。

この違いは、テキストファイルの比較作業や、特定のビルドツールによっては不具合の原因になります。
たとえば、ビルドスクリプトでLFのみ想定している環境にCRLFのファイルを持ち込むと、実行時にエラーが起きることがあります。
こうした摩擦をできるだけ減らすためにも、改行コードの扱いには注意が必要です。

git autocrlfの設定値

git autocrlfには、いくつか設定のパターンがあります。
true・input・falseの3種類があり、それぞれの動作が異なる点がポイントです。

true

チェックアウト時にLFをCRLFへ変換し、コミット時にはCRLFをLFへ自動変換します。
Windowsユーザーが多いプロジェクトでよく使われる設定です。

input

チェックアウト時の変換は行わず、コミット時にCRLFをLFへ変換します。
LinuxやmacOSユーザーに向いている設定と言えます。

false

何も変換しません。
チームで統一したルールがある場合、あえてfalseにすることもありますが、初心者の方はtrueかinputを使う場面が多いでしょう。

この設定を行うには、以下のようにコマンドを使います。


# Windows環境での例
git config --global core.autocrlf true

# LinuxやmacOSでの例
git config --global core.autocrlf input

# 変換を無効にする場合
git config --global core.autocrlf false

なお、プロジェクトごとに設定を分けたい場合は、--global を外してリポジトリ内で直接設定するのも一つの手段です。
チーム開発の場合は、メンバー全員で方針を決めて共有することがトラブルを減らすコツです。

実務での活用シーン

実務で開発していると、多様なOSを使うチームメンバーが同じリポジトリにコミットすることがあります。
たとえば、WindowsユーザーとLinuxユーザーが混在した環境で開発している場合、改行コードの不一致が原因でファイル差分が大きくなるケースが見受けられます。

このような場合、git autocrlf を適切に設定しておくと、あらかじめ改行コードを揃えてくれるため、差分が改行コードであふれてしまう現象を避けられます。
また、後からでも設定を整えれば、次回以降のコミットで改行コードが自動的に整備されるので、バグが出やすいスクリプトなどでも動作が安定しやすくなります。

特に、バッチファイルやシェルスクリプトを扱うプロジェクトでは、Windows向けに書かれたコードをLinuxサーバーにデプロイする機会があるかもしれません。
こうした場面で、余計な改行コードの修正に時間を取られなくてすむという利点も大きいでしょう。

チーム開発での注意点

チームで同じリポジトリを使う場合、改行コードに関する設定を事前に話し合っておくことが大切です。
特に、WindowsユーザーとLinuxユーザーが混在している場合、autocrlfをどうするかによってファイルの変更履歴が大きく変わる可能性があります。

一度作業が進んだ後で設定を変えると、大量の差分が生じることもあります。
こうした事態を回避するために、新規プロジェクトの立ち上げ時には、core.autocrlfの設定方針を決めておくと良いでしょう。
また、リポジトリに**.gitattributes**ファイルを置き、ファイルごとの改行ルールを明示的に記述する方法もあります。
こうすることで、特定の拡張子だけはLFに固定するといった細かい制御が可能です。

レポジトリの統一とルール決め

改行コードの取り扱いは、チームのコーディング規約の一部と考えることが大切です。
たとえば以下のようなルールを決めると、後から混乱が起きにくくなります。

core.autocrlf はプロジェクト全員が同じ設定を使う
Windowsユーザーはtrue、LinuxやmacOSユーザーはinput、あるいは全員がinputを使うなど、統一方針を決める
必要に応じて**.gitattributes**で拡張子ごとの改行コードを指定する

こうした取り決めがないと、改行コードの修正が不要なはずのファイルに差分が付いてしまい、コミットの内容を追いかけるのが大変になります。
特に、テキストベースの設定ファイルを多用するプロジェクトでは、ローカルでしか動かない原因が改行コードだったというケースが少なくありません。

よくあるトラブルと対処法

改行コードが統一されていないと、以下のようなトラブルが起こりやすくなります。
ここでは、その対処方法についても解説します。

改行コードの差分が大量に発生する

既存のプロジェクトに後からautocrlfを設定してしまうと、変更していないはずのファイルで大量の差分が発生することがあります。
この場合は、差分をコミットしてリポジトリをリセットするか、設定を一度リセットしてからコミットするなど、チームと相談して整合性を取る必要があります。

スクリプトが正しく動作しない

Windows用に作ったバッチファイルをLinuxで動かそうとしたり、逆にLinux向けのシェルスクリプトをWindowsで実行しようとすると、改行コードの違いが原因で予期せぬエラーが出る場合があります。
このときは、autocrlfや.gitattributesで該当ファイルの改行コードを統一しておくと対処が容易です。

改行コードの問題は目に見えにくいため、一度設定に失敗すると原因を特定するのが難しくなることがあります。
そのため、プロジェクトの開始段階で早めに決めておくのがおすすめです。

git autocrlf と .gitattributes の組み合わせ

.gitattributesファイルを使うと、個別の拡張子ごとに改行コードを強制的に指定できます。
たとえば、ソースコードはLFにしたいけれど、バッチファイルはCRLFで扱いたいといった場合に役立ちます。
設定例は以下のとおりです。


# 例: .gitattributes
*.sh      text eol=lf
*.bat     text eol=crlf
*.txt     text eol=lf

このようにファイル単位で改行コードを指定しておくと、チームの誰がコミットしても、特定のファイルは指定した改行コードに揃えられます。
これによって、ローカル環境の設定に依存せずに明確なルールを持てるようになるため、より安定した開発が可能になります。

まとめ

改行コードは、普段は意識されにくいものの、チーム開発では大きな混乱を引き起こす要因になりやすい要素の一つです。
git autocrlfを使えば、Windows・Linux・macOSなど異なるOS環境をまたいでも、改行コードを自動的に整えてくれます。
設定を誤ると、思わぬ差分が大量に生まれてしまうこともあるため、プロジェクト開始時や新しいメンバーが加わるタイミングで、一度方針を確認しておくことが大切です。

core.autocrlfの値としては、Windowsユーザーが多い場合はtrue、LinuxやmacOSが中心のプロジェクトならinputなど、状況に合わせて最適な設定を選びましょう。
さらに、必要に応じて**.gitattributes**ファイルで拡張子ごとに細かく指定することで、チーム全体での開発体験をスムーズに保つことができます。

改行コードを統一しておくと、コードレビューやバグ修正にかける余計な手間が減り、本来取り組みたい機能開発や改善に集中しやすくなるでしょう。
これを機会に、プロジェクト全体での改行コードの取り扱いを見直してみてはいかがでしょうか。