「Gitでファイルをコミットしたら、何も変更していないのに全行が変更扱いになってる…」「チェックアウトしたらシェルスクリプトが動かなくなった！」こんな経験はありませんか？
これは、Gitの改行コード自動変換機能が原因で起こる典型的なトラブルです。Windows（CRLF）とLinux/Mac（LF）の間で開発していると、知らないうちにファイルの改行コードが変換されてしまい、思わぬ問題を引き起こします。
この記事では、Gitの改行コード問題の仕組みを徹底解説し、OS別の推奨設定から.gitattributesを使った確実な対策方法まで、すべてをカバーします。
- 改行コードとは？LF・CRLF・CRの違い
- Gitで改行コードが勝手に変わる理由
- 改行コード問題が引き起こす具体的なトラブル
- 現在の設定を確認する方法
- OS別の推奨設定
- .gitattributes による確実な改行コード管理
- 既存リポジトリの改行コードを修正する
- トラブルシューティング
- よくある質問（FAQ）
- Q1：core.autocrlfはtrueとfalse、どちらにすべきですか？
- Q2：.gitattributesとcore.autocrlf、どちらが優先されますか？
- Q3：既存のcommit履歴の改行コードも変更されますか？
- Q4：バイナリファイルも自動変換されますか？
- Q5：Gitのバージョンによって動作が違いますか？
- Q6：MacとWindowsが混在するチームの推奨設定は？
- Q7：.gitattributesはどこに置けばいいですか？
- Q8：改行コードの混在をコミット前にチェックできますか？
- Q9：GitHub ActionsやCIでも設定が必要ですか？
- Q10：Windows専用プロジェクトでもLFにすべきですか？
- まとめ：改行コード問題を完全に解決する
改行コードとは？LF・CRLF・CRの違い
まず基本から。改行コードとは、テキストファイルで「改行」を表現するための制御文字です。実は、OSによって使用する改行コードが異なります。
3種類の改行コード
| 改行コード | 正式名称 | 制御文字 | 使用OS | 記号表示 |
|---|---|---|---|---|
| LF | Line Feed（ラインフィード） | \n | Linux、Mac（macOS）、Unix | ↓ |
| CRLF | Carriage Return + Line Feed | \r\n | Windows | ↵ |
| CR | Carriage Return（キャリッジリターン） | \r | 旧Mac OS（9以前） | ← |
簡単に言うと：
- LF：「次の行に移動」（↓だけ）
- CRLF：「行頭に戻って次の行に移動」（←と↓の組み合わせ）
- CR：「行頭に戻る」（←だけ）※現在はほぼ使われない
なぜOSによって改行コードが違うのか？
これは歴史的な経緯があります。
タイプライター時代の名残：
- CR（Carriage Return）：タイプライターの印字ヘッドを左端に戻す動作
- LF（Line Feed）：紙を1行分上に送る動作
- 物理的に2つの動作が必要だった
コンピュータでの採用：
- Unix/Linux：効率重視でLFのみを採用
- Windows（MS-DOS）：タイプライターの動作を忠実に再現してCRLF
- 旧Mac OS：独自路線でCRのみ（現在のmacOSはLF）
この違いが、現代のクロスプラットフォーム開発で問題を引き起こしているのです。
Gitで改行コードが勝手に変わる理由
Gitには、この改行コードの違いを「自動的に吸収してくれる」機能があります。それがcore.autocrlf設定です。
core.autocrlfの仕組み
Gitは、コミット時とチェックアウト時に改行コードを自動変換します。
動作イメージ：
【Windowsユーザー】
ローカル（作業ディレクトリ） ←→ リポジトリ
CRLF ファイル ←→ LF ファイル
↑ チェックアウト時 ↑ コミット時
| LF → CRLF 変換 | CRLF → LF 変換core.autocrlfの3つの設定値
| 設定値 | コミット時 | チェックアウト時 | 推奨OS |
|---|---|---|---|
| true | CRLF → LF | LF → CRLF | Windows |
| input | CRLF → LF | 変換しない | Linux、Mac |
| false | 変換しない | 変換しない | – |
具体的な動作：
core.autocrlf = true（Windows推奨）
コミット時：
ローカル CRLF ファイル → リポジトリ LF ファイル
チェックアウト時：
リポジトリ LF ファイル → ローカル CRLF ファイル- 利点：Windowsアプリが正常に動作（メモ帳等がCRLF前提）
- 欠点：全員が同じ設定でないと混乱する
core.autocrlf = input（Linux/Mac推奨）
コミット時：
ローカル CRLF ファイル → リポジトリ LF ファイル
チェックアウト時：
リポジトリ LF ファイル → ローカル LF ファイル（そのまま）- 利点：誤ってCRLFがコミットされても自動修正
- 欠点：Windows特有ファイル（.batなど）で問題が起きる可能性
core.autocrlf = false（非推奨）
コミット時：変換なし
チェックアウト時：変換なし- 利点：Gitが余計なことをしない（シンプル）
- 欠点：チーム内でOSが混在すると改行コード混在の温床に
Git for Windowsのデフォルト設定
重要： Git for Windowsをインストールすると、デフォルトでcore.autocrlf = trueになります。
インストール時の選択画面：
Configuring the line ending conversions
○ Checkout Windows-style, commit Unix-style line endings
(推奨) core.autocrlf = true
○ Checkout as-is, commit Unix-style line endings
core.autocrlf = input
○ Checkout as-is, commit as-is
core.autocrlf = false多くの人は何も考えずに推奨設定でインストールしてしまい、後で問題に遭遇します。
改行コード問題が引き起こす具体的なトラブル
トラブル1：シェルスクリプトが動かない
症状：
$ bash deploy.sh
bash: ./deploy.sh: /bin/bash^M: bad interpreter: No such file or directory原因：
- シェルスクリプトがCRLFでチェックアウトされた
- Linuxは行末の
^M（CR）を誤認識してコマンドが見つからない
影響：
- Linuxサーバーでのデプロイ失敗
- Dockerコンテナ内での実行エラー
- 夜間バッチ処理の停止 → 本番障害
トラブル2：全行が変更扱いになる
症状：
$ git diff README.md
- 全ての行が削除（赤）
+ 全ての行が追加（緑）
実際の内容は何も変わっていない原因：
- リポジトリはLFで管理
core.autocrlf = falseの環境でCRLFファイルをコミット- 改行コード以外は同じなのに「全行変更」と判定
影響：
- コードレビューが不可能
- マージコンフリクトが大量発生
git blameが使えない
トラブル3：diffに謎の^Mが表示される
症状：
$ git diff
-Hello World
+Hello World^M原因：
- リポジトリにCRLFが混入している
- Gitが「CRLFとLFのファイルが違う」と判定
影響：
- 差分が見にくい
- 実際の変更箇所が分からない
トラブル4：Dockerコンテナが起動しない
症状：
$ docker-compose up
ERROR: Service 'app' failed to start:
exec /app/entrypoint.sh: no such file or directory原因：
entrypoint.shがCRLFでチェックアウトされた- Linux環境のDockerコンテナ内で実行できない
影響：
- 開発環境が構築できない
- CIが失敗する
現在の設定を確認する方法
トラブルシューティングの第一歩は、現状把握です。
core.autocrlfの設定を確認
グローバル設定を確認：
git config --global core.autocrlf出力例：
true # Windowsデフォルト（自動変換ON）
input # Linux/Macで推奨
false # 自動変換OFF
（何も表示されない）# 設定されていない（falseと同じ扱い）リポジトリ固有の設定を確認：
git config --local core.autocrlf設定の優先順位を確認：
git config --show-origin core.autocrlf出力例：
file:C:/Users/username/.gitconfig trueこれで、設定がどこで定義されているかが分かります。
ファイルの改行コードを確認
方法1：git ls-files --eolコマンド（Git 2.10以降）
git ls-files --eol出力例：
i/lf w/crlf attr/text=auto README.md
i/lf w/lf attr/text=auto deploy.sh
i/crlf w/crlf attr/ data.csv読み方：
i/lf：インデックス（リポジトリ）内はLFw/crlf：作業ディレクトリ（ワーキングツリー）内はCRLFattr/text=auto：.gitattributesの設定
方法2：fileコマンド（Linux/Mac）
file deploy.sh出力例：
deploy.sh: Bourne-Again shell script, ASCII text executable, with CRLF line terminators方法3：dos2unix -iコマンド
dos2unix -i *.sh出力例：
123 0 deploy.sh # 123行がDOS形式（CRLF）
0 89 setup.sh # 89行がUnix形式（LF）方法4：リポジトリ内でCRLFを検索
git grep --cached -I $'\r'CRLFが含まれるファイルが表示されます。何も表示されなければ、リポジトリは正常（LFのみ）です。
エディタで確認
Visual Studio Code：
画面右下のステータスバー：
「LF」または「CRLF」と表示されるVim：
:set fileformat?出力：
fileformat=unix (LF)
fileformat=dos (CRLF)
fileformat=mac (CR)OS別の推奨設定
チーム開発では、全員が統一した方針で設定することが重要です。
基本方針：リポジトリは常にLFで統一
推奨アプローチ：
- リポジトリ内：常にLF（改行コード混在を防ぐ）
- ローカル環境：OSに応じて調整（Windows = CRLF、Linux/Mac = LF）
- 強制力：
.gitattributesで制御（後述）
Windows での推奨設定
パターンA：自動変換ON（初心者向け）
git config --global core.autocrlf trueメリット：
- Windowsアプリ（メモ帳、Excel等）でファイルが正しく表示される
- リポジトリは自動的にLFで統一される
デメリット：
- バイナリファイルが破損するリスク（稀）
- Dockerやシェルスクリプトで問題が起きやすい
推奨する人：
- Gitを初めて使うWindowsユーザー
- Windows専用のプロジェクト（.NET Frameworkアプリ等）
パターンB：自動変換OFF + .gitattributes（推奨）
git config --global core.autocrlf falseその上で、プロジェクトルートに.gitattributesを配置（後述）。
メリット：
- ファイル種別ごとに改行コードを制御できる
- チーム全体で統一しやすい
- バイナリファイルの破損リスクなし
デメリット：
.gitattributesの理解が必要- 既存プロジェクトへの適用には手間がかかる
推奨する人：
- チーム開発をしているすべての人
- Docker、Linux環境を使うプロジェクト
Linux / Mac での推奨設定
git config --global core.autocrlf input動作：
- コミット時：CRLFが混入していたらLFに変換（防御）
- チェックアウト時：変換しない（LFのまま）
理由：
- 通常、Linux/Macでは全てLFなので変換不要
- 万が一CRLFファイルが混入してもコミット時に自動修正
- シェルスクリプト等が確実にLFで動作
設定の実例
Windows開発者の理想的な設定：
# グローバル設定は無効化
git config --global core.autocrlf false
# プロジェクトごとに .gitattributes で制御
# （後述の .gitattributes セクションを参照）Linux/Mac開発者の理想的な設定：
# CRLFの混入を防ぐ
git config --global core.autocrlf input.gitattributes による確実な改行コード管理
.gitattributesは、リポジトリに含めることで全員に同じルールを強制できる最も確実な方法です。
.gitattributesの基本
.gitattributesファイルをプロジェクトルートに配置すると、core.autocrlfの設定を上書きします。
基本構文：
ファイルパターン 属性改行コード制御の属性
| 属性 | 意味 | 動作 |
|---|---|---|
text | テキストファイル | 常にLFで管理（コミット時にCRLF→LF） |
text=auto | 自動判別 | Gitがテキストかバイナリか判定 |
text eol=lf | LF強制 | チェックアウト時も常にLF |
text eol=crlf | CRLF強制 | チェックアウト時は常にCRLF |
binary | バイナリ | 変換しない（-text -diffのエイリアス） |
-text | テキストとして扱わない | 変換しない |
推奨 .gitattributes テンプレート
基本版（シンプル）：
# デフォルトはGitに判定させる
* text=auto
# シェルスクリプトは必ずLF
*.sh text eol=lf
*.bash text eol=lf
# Windowsバッチファイルは必ずCRLF
*.bat text eol=crlf
*.cmd text eol=crlf
*.ps1 text eol=crlf
# バイナリファイル
*.png binary
*.jpg binary
*.gif binary
*.ico binary
*.pdf binary
*.zip binary
*.tar.gz binary詳細版（完全）：
##############################################################
# 改行コード管理設定
# リポジトリは常にLF、チェックアウト時に必要に応じて変換
##############################################################
# デフォルト：Gitに自動判定させる
* text=auto
#
# テキストファイル（LF強制）
#
# ソースコード
*.c text eol=lf
*.cpp text eol=lf
*.h text eol=lf
*.java text eol=lf
*.py text eol=lf
*.rb text eol=lf
*.go text eol=lf
*.rs text eol=lf
# Web関連
*.js text eol=lf
*.ts text eol=lf
*.jsx text eol=lf
*.tsx text eol=lf
*.html text eol=lf
*.css text eol=lf
*.scss text eol=lf
*.sass text eol=lf
*.vue text eol=lf
# マークアップ・設定ファイル
*.md text eol=lf
*.txt text eol=lf
*.json text eol=lf
*.xml text eol=lf
*.yaml text eol=lf
*.yml text eol=lf
*.toml text eol=lf
# シェルスクリプト（必ずLF）
*.sh text eol=lf
*.bash text eol=lf
# Dockerfile
Dockerfile text eol=lf
*.dockerfile text eol=lf
# Makefile
Makefile text eol=lf
*.mk text eol=lf
# Git関連
.gitattributes text eol=lf
.gitignore text eol=lf
.gitconfig text eol=lf
#
# Windows専用ファイル（CRLF強制）
#
# バッチファイル
*.bat text eol=crlf
*.cmd text eol=crlf
# PowerShellスクリプト
*.ps1 text eol=crlf
*.psm1 text eol=crlf
*.psd1 text eol=crlf
# Visual Studioプロジェクト
*.sln text eol=crlf
*.csproj text eol=crlf
*.vbproj text eol=crlf
#
# バイナリファイル（変換しない）
#
# 画像
*.png binary
*.jpg binary
*.jpeg binary
*.gif binary
*.ico binary
*.bmp binary
*.svg binary
*.webp binary
# フォント
*.ttf binary
*.otf binary
*.woff binary
*.woff2 binary
*.eot binary
# 圧縮ファイル
*.zip binary
*.tar binary
*.gz binary
*.bz2 binary
*.7z binary
*.rar binary
# オフィス文書
*.pdf binary
*.doc binary
*.docx binary
*.xls binary
*.xlsx binary
*.ppt binary
*.pptx binary
# 実行ファイル
*.exe binary
*.dll binary
*.so binary
*.dylib binary
*.app binary
# データベース
*.db binary
*.sqlite binary
*.sqlite3 binary
# その他
*.jar binary
*.war binary
*.ear binary
*.class binary
*.pyc binary.gitattributesの配置と適用
ステップ1：ファイルを作成
cd /path/to/your/repository
# エディタで作成
vi .gitattributesステップ2：コミット
git add .gitattributes
git commit -m "Add .gitattributes for line ending normalization"ステップ3：既存ファイルを正規化（重要！）
.gitattributesを追加しただけでは、既存ファイルには適用されません。
# 方法1：全ファイルを再正規化（Git 2.16以降）
git add --renormalize .
# 方法2：強制的に再チェックアウト（古いGit）
git rm --cached -r .
git reset --hardステップ4：コミット
git commit -m "Normalize line endings"警告：
この操作は、多数のファイルが変更扱いになる可能性があります。チーム全体に事前通知してから実行しましょう。
既存リポジトリの改行コードを修正する
すでに改行コードが混在しているリポジトリを直す手順です。
手順1：現状確認
# リポジトリ内のCRLFを検索
git grep --cached -I $'\r'大量にヒットする場合は、リポジトリにCRLFが混入しています。
手順2：core.autocrlfをfalseに設定
# グローバル設定を確認
git config --global core.autocrlf
# falseでなければ変更
git config --global core.autocrlf false
# リポジトリ固有設定も確認
cd /path/to/repository
git config core.autocrlf false手順3：.gitattributesを作成
# プロジェクトルートで
cat > .gitattributes <<'EOF'
* text=auto eol=lf
# Windows専用ファイル
*.bat text eol=crlf
*.cmd text eol=crlf
*.ps1 text eol=crlf
# バイナリ
*.png binary
*.jpg binary
*.pdf binary
EOF
git add .gitattributes
git commit -m "Add .gitattributes"手順4：全ファイルを再正規化
# ステージングエリアをクリア
git rm --cached -r .
# すべてのファイルを再度追加（.gitattributesに従って変換される）
git add .
# 何が変わったか確認
git status大量のファイルが変更扱いになるはずです。
手順5：変更をコミット
git commit -m "Normalize line endings to LF"手順6：チームメンバーに通知
他のメンバーがすべきこと：
# 最新をpull
git pull
# 作業中の変更を一時退避
git stash
# ローカルファイルをクリーンアップ
git rm --cached -r .
git reset --hard
# 退避した変更を戻す
git stash pop手順7：確認
# 改行コードを確認
git ls-files --eol
# CRLFが残っていないか確認
git grep --cached -I $'\r'何も出力されなければ成功です！
トラブルシューティング
問題1：「warning: LF will be replaced by CRLF」
症状：
$ git add file.txt
warning: LF will be replaced by CRLF in file.txt.
The file will have its original line endings in your working directory原因：
core.autocrlf = true（Windowsデフォルト）- ファイルはLFだが、チェックアウト時にCRLFに変換される予定
対処法：
即効性：警告を無視する
# 警告は無害（単なる通知）
# そのままコミット可能
git commit -m "Update file"根本的解決：設定を変更
# パターンA：自動変換を無効化
git config --global core.autocrlf false
# パターンB：.gitattributesで制御
echo "* text=auto eol=lf" > .gitattributes
git add .gitattributes
git commit -m "Add .gitattributes"問題2：「warning: CRLF will be replaced by LF」
症状：
$ git add file.txt
warning: CRLF will be replaced by LF in file.txt.原因：
core.autocrlf = inputまたはtrue- ファイルにCRLFが含まれており、コミット時にLFに変換される
対処法：
意図的にCRLFを保持したい場合：
# .gitattributes でCRLF強制
echo "file.txt text eol=crlf" >> .gitattributes
git add .gitattributes
git add file.txtLFに統一したい場合：
# そのままコミット（自動的にLFになる）
git commit -m "Update file"問題3：シェルスクリプトが「bad interpreter」エラー
症状：
$ ./deploy.sh
bash: ./deploy.sh: /bin/bash^M: bad interpreter: No such file or directory原因：
- スクリプトがCRLFでチェックアウトされた
- Linuxは
\r\nを認識できない
即座の対処：
# dos2unix で変換
dos2unix deploy.sh
# または sed で変換
sed -i 's/\r$//' deploy.sh
# または tr で削除
tr -d '\r' < deploy.sh > deploy_fixed.sh
mv deploy_fixed.sh deploy.sh根本的解決：
# .gitattributes でLF強制
echo "*.sh text eol=lf" >> .gitattributes
git add .gitattributes
# スクリプトを再チェックアウト
git rm --cached deploy.sh
git checkout deploy.sh
# コミット
git commit -m "Fix shell script line endings"問題4：全行が変更扱いになる
症状：
$ git diff
-すべての行が削除
+すべての行が追加原因：
- 改行コードだけが変わった
- Gitは「全行変更」と判定
確認方法：
# 改行コード変更を無視してdiff
git diff --ignore-cr-at-eol
# または
git diff --ignore-all-space修正方法：
# 改行コードを統一
# （前述の「既存リポジトリの修正」セクションを参照）問題5：.gitattributesが効かない
症状：
.gitattributesを追加したのに変換されない
原因：
- 既存ファイルには適用されない
解決方法：
# 強制的に再正規化
git add --renormalize .
git commit -m "Apply .gitattributes"
# または
git rm --cached -r .
git reset --hard問題6：Dockerコンテナでスクリプトが実行できない
症状：
exec /app/entrypoint.sh: no such file or directory原因：
entrypoint.shがCRLFになっている
解決方法：
Dockerfile内で強制的にLF変換：
FROM ubuntu:22.04
COPY entrypoint.sh /app/
# LFに強制変換
RUN sed -i 's/\r$//' /app/entrypoint.sh && \
chmod +x /app/entrypoint.sh
ENTRYPOINT ["/app/entrypoint.sh"]または、.gitattributesで防止：
*.sh text eol=lf
Dockerfile text eol=lfよくある質問（FAQ）
Q1：core.autocrlfはtrueとfalse、どちらにすべきですか？
A： チーム全体で.gitattributesを使うならfalseを推奨します。
理由：
.gitattributesがより強力で柔軟- リポジトリに含めるので全員に強制できる
- ファイルごとに改行コードを制御可能
ただし：
- 1人で開発しているWindowsユーザーなら
trueでもOK - Linux/Macユーザーは
inputが無難
Q2：.gitattributesとcore.autocrlf、どちらが優先されますか？
A： .gitattributesが優先されます。
優先順位：
1. .gitattributes（最優先）
2. core.autocrlf
3. デフォルト動作チーム開発では.gitattributesを使うべき理由です。
Q3：既存のcommit履歴の改行コードも変更されますか？
A： いいえ、過去のコミットは変更されません。
.gitattributesや設定変更は、新しいコミットにのみ影響します。
もし過去のコミットを修正したい場合は、git filter-repoなどの高度なツールが必要ですが、推奨しません（履歴が書き換わるため）。
Q4：バイナリファイルも自動変換されますか？
A： 基本的にされませんが、念のため明示すべきです。
Gitは一応バイナリ判定をしますが、完璧ではありません。
推奨：
*.png binary
*.jpg binary
*.pdf binary
*.exe binaryQ5：Gitのバージョンによって動作が違いますか？
A： 基本的な動作は同じですが、一部コマンドが異なります。
主な違い：
- Git 2.16以降：
git add --renormalizeが使える - Git 2.10以降：
git ls-files --eolが使える - 古いGit：上記コマンドが使えない（別の方法が必要）
古いGitを使っている場合は、アップデートを検討してください。
Q6：MacとWindowsが混在するチームの推奨設定は？
A： 全員が以下の設定にすることを推奨します。
Windowsユーザー：
git config --global core.autocrlf falseMac/Linuxユーザー：
git config --global core.autocrlf input全員共通：
プロジェクトルートに.gitattributesを配置：
* text=auto eol=lf
# Windows専用ファイルのみCRLF
*.bat text eol=crlf
*.cmd text eol=crlf
*.ps1 text eol=crlf
# バイナリ
*.png binary
*.jpg binaryQ7：.gitattributesはどこに置けばいいですか？
A： プロジェクトのルートディレクトリに置きます。
your-project/
├── .git/
├── .gitattributes ← ここ
├── .gitignore
├── README.md
└── src/サブディレクトリに配置することも可能ですが、通常はルートに1つだけで十分です。
Q8：改行コードの混在をコミット前にチェックできますか？
A： はい、core.safecrlfを有効にすると警告してくれます。
# 警告のみ表示（コミットは継続）
git config --global core.safecrlf warn
# エラーでコミットを拒否
git config --global core.safecrlf true動作：
true：改行コードが混在している場合、コミットを拒否warn：警告を表示するがコミットは実行false：何もチェックしない（デフォルト）
Q9：GitHub ActionsやCIでも設定が必要ですか？
A： .gitattributesがあれば不要です。
CI環境でも.gitattributesの設定が適用されます。ただし、念のため確認コマンドを追加することを推奨：
# GitHub Actions の例
name: Check Line Endings
on: [push, pull_request]
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Check for CRLF
run: |
if git grep --cached -I $'\r' ; then
echo "❌ CRLF found in repository!"
exit 1
else
echo "✅ All files use LF"
fiQ10：Windows専用プロジェクトでもLFにすべきですか？
A： 場合によります。
LFを推奨するケース：
- Docker、Linux環境を使う可能性がある
- オープンソースプロジェクト
- 将来的にクロスプラットフォーム化する可能性
CRLFでもOKなケース：
- 完全にWindows専用（.NET Framework等）
- 外部公開しない社内ツール
- レガシーシステムの保守
その場合の設定：
* text=auto eol=crlfただし、一般的にはLF統一を推奨します。将来の拡張性が高いためです。
まとめ：改行コード問題を完全に解決する
Gitの改行コード自動変換は、便利なようで罠が多い機能です。特にチーム開発では、メンバー間で設定が異なると混乱の元になります。
推奨アプローチ：
- 個人設定を統一
- Windows：
git config --global core.autocrlf false - Mac/Linux：
git config --global core.autocrlf input
- プロジェクトに
.gitattributesを追加
* text=auto eol=lf
*.bat text eol=crlf
*.cmd text eol=crlf
*.ps1 text eol=crlf
*.png binary
*.jpg binary- 既存リポジトリを正規化
git add --renormalize .
git commit -m "Normalize line endings"- チーム全体で方針を共有
- READMEに記載
- オンボーディング時に説明
- プルリクエストでレビュー
最重要ポイント：
- ✅ リポジトリは常にLFで統一
- ✅
.gitattributesで制御する（個人設定に依存しない） - ✅ バイナリファイルは明示する
- ✅ チーム全体で統一した設定を使う
- ❌
core.autocrlf = trueに依存しない
この記事の手順に従えば、改行コード問題から完全に解放されます。快適なGitライフを！
参考リンク：
コメント