😎

Git の core.autocrlf と .gitattributes の考え方

に公開
Git
Linux
WSL 2
macOS
Git Bash
tech

0. この記事のゴール

  • 開発用 PC 自体は Windows 11 / macOS / ネイティブ Linux のいずれでもよい。
  • ただし本記事では、特に Windows 11 の場合に「Git を WSL2（Linux） と Git for Windows（Git Bash 等） の2種類」を考慮して扱う。

それから、

  • a) Linux ベースで開発する方が自然なケース
  • b) Windows ベースで開発する方が自然なケース

この 2 つの軸をちゃんと分けて考えたうえで、次の構成がなぜおすすめかを説明します。

macOS やネイティブ Linux PC でも、「リポジトリ内は LF に正規化する」の思想自体は同じはず
macOS やネイティブ Linux PCは、当記事内のWSL2として読み替えてください
macOS やネイティブ Linux PCの場合で b) の組み合わせ での
開発は現実には、ほぼない。 b)の開発するときは、ほぼ、Windows PCを用意しての開発になる。
そのため、macOS やネイティブ Linux PCの場合で b) の組み合わせ は、無視して下さい

当記事としては、結論として、下記の1)、2)、3)の設定をすることをオススメとしてます
後述で一部 GitHub Docs の参照先も書いてますが、GitHub Docs での記述に基づいてます
他の考え方をしてる人がいることは承知しております

1) WSL2 側 Git

git config --global core.autocrlf input

2) Windows Git Bash 側 Git（Git for Windows）

git config --global core.autocrlf true

3) 各リポジトリのルートに .gitattributes

* text=auto

1)、2) の目的としては、各環境の作業ツリーの改行コードを「WSL2 側は LF、Windows Git Bash 側は CRLF」にしつつ、コミット時にはどちらも自動的に LF に直してからリポジトリに保存させるためです。

3) の目的としては、開発者それぞれの core.autocrlf 設定に関係なく、リポジトリ内のテキストファイルの改行コードを LF 一択に統一するためです。

★★★★★★★★★★★★
★ ＜2025/12/09追記＞★
★★★★★★★★★★★★
Visual Studio Community 2026の「Gitの作成」のUI操作でリポジトリの環境を作った場合は、
.gitattributes が自動作成され、中身に * text=auto がちゃんとありました。
GitHubを買収したMicrosoftが作ったツールで「Gitの作成」のUI操作でGitHub Docs推奨のやり方で自動で、こうなるのは自然な事でしょう
★★★★★★★★★★★★

★★★★★★★★★★★★
★ ＜2026/02/01追記＞★
★★★★★★★★★★★★
WSL2のubuntuのターミナルで、git initすると
.gitattributes に、

* text=auto eol=lf

が追加された
*：全ファイルに適用（この行の属性指定を、対象パターン * に一致するパスへ適用）
text=auto：Git が 「テキストファイルだ」と判断したものについて、改行コードの正規化（EOL変換）対象にする指定です。Git はテキストと判断した場合、リポジトリに格納する内容は LF に正規化します（※ただし、既に CRLF でコミットされている等では変換しない場合がある、という仕様も記載されています）。
eol=lf：作業ツリー（checkout 後の実ファイル）の改行コードを LF に固定する指定です。eol は「作業ディレクトリで使う行末」を指定し、実質的に text を有効化します。さらに eol=lf は「checkin 時に LF に正規化し、checkout 時に CRLF へ変換することをしない（＝LFのままにする）」という意味です。

要するに、このリポジトリでは（原則）改行を LF で統一するための設定です。特に eol=lf は「checkout 後も LF」の固定が主目的です。
★★★★★★★★★★★★

注意: ここで示す構成は、GitHub 公式ドキュメントなどでも紹介されている「Windows では core.autocrlf=true、Linux / macOS / WSL2 では core.autocrlf=input、リポジトリ側では .gitattributes で * text=auto を指定して LF に正規化する」という流儀に沿った「一例」です。
他にも、全環境で core.autocrlf=false にして、.gitattributes のみで改行コードを統一管理する流儀もあります。
本記事では「WSL2 と Git for Windows の2種類」を想定し、運用しやすさの観点からこの構成を おすすめ構成 として採用しています。

これが、リポジトリ内は LF に揃えたいときに、Git 公式ドキュメントでも紹介されている代表的なやり方です。
（※ 他にも、core.autocrlf=false を全環境で使い、.gitattributes だけで改行コードを管理する流儀も現実に存在します。その場合も、最終的には「リポジトリ内は LF に正規化する」ことが多く、この章で説明した考え方自体は共通です。）

この考え方とほぼ同じ構成を、そのまま例示している公式ドキュメントとして、GitHub Docs に次の記述があります。

さらに、次の点もきちんと説明します。

  • WSL2 / Git Bash それぞれで 改行コードを置換する必要があるか / やってはいけないか / やってもよいが不要か。
    ( Windowsユーザは、sakuraエディタで\r\nを\nを全置換する操作をよくやると思います )
  • a) / b) と WSL2 / Git Bash の組み合わせ 4 パターンで、行末がどう扱われるか。
  • Git for Windows インストーラーの「改行コードに関する 3 つの選択肢」と core.autocrlf との対応。

1. 前提となる 2 つの開発パターン a) / b)

まず、この記事での分類をはっきりさせます。

a) Linux ベースで開発する方が自然なケース

代表的には、この記事では次のようなスタックを a) に含めて話を進めます。

  • PHP + Laravel
  • Ruby on Rails
  • Python + Django / FastAPI
  • Node.js 系フレームワーク（React / Next.js / NestJS など）
  • Go / Rust の Web API サーバー
  • コンテナ前提（Docker / Kubernetes）で本番も Linux で動かすもの

最終的に本番で動く OS が Linux であることが多いので、

  • 本番環境
  • CI サーバー
  • Docker コンテナの中

など、どこを取っても LF 改行（Unix スタイル）が素直な世界です。

この記事ではこれを a) のプロジェクトと呼びます。

b) Windows ベースで開発する方が自然なケース

代表的には次のような開発です。

  • C# / .NET での Windows デスクトップアプリ（WinForms / WPF など）
  • Windows 向けのツール類（バッチ、PowerShell スクリプト中心のもの など）
  • 企業内で配布する Windows 専用クライアントアプリ

また、実行環境は Linux でも、開発用 PC とツールが完全に Windows 前提な現場も、実務上は b) 寄りの性格を持ちます。
例えば、Java でサーバーサイドを実装して本番は Linux 上で動かすが、Java は基本的にプラットフォーム非依存であり、日付やロケールなどを共通部品で揃えておけば Windows で開発しても本番 Linux で問題になりにくいため、開発用 PC や IDE はコストの安い Windows ノートに統一されている、といったケースです。

この記事ではこれを b) のプロジェクトと呼びます。

2. 行末コード（LF / CRLF）と Git の前提

2.1 2 種類の行末コード

  • LF (\n)
    • Unix / Linux / macOS / WSL2 などの標準的な行末
  • CRLF (\r\n)
    • Windows 上の多くのツールで使われる行末（メモ帳、PowerShell、Git Bash など）

テキストファイルの中身自体は同じでも、LF か CRLF かだけが違うという状態はごく普通に発生します。

なお、本記事に登場する環境での「素の状態」の行末はおおむね次のとおりです。

  • WSL2 上で作成・編集するファイル … 基本的に LF
  • Windows 上の Git Bash から作成・編集するファイル … 基本的に CRLF
  • 上記以外の Windows ネイティブアプリ（メモ帳など） … ほぼ CRLF

2.2 Git は基本的には「中身をそのまま保存」する

Git はデフォルトでは「渡されたバイト列」をそのまま保存します。
しかし、設定次第で、行末に関しては自動変換（LF に正規化 / CRLF に変換）を行うことができます。

そのための仕組みが次の 2 つです。

  • core.autocrlf（Git 設定）
  • .gitattributes（ファイルごとの属性指定）

3. core.autocrlf の公式仕様（要点）

公式ドキュメント（git-config）では core.autocrlf について次のように説明されています。

  • Git 公式ドキュメント
    https://git-scm.com/docs/git-config

    core.autocrlf が true のとき、チェックアウト時に LF を CRLF に、コミット時に CRLF を LF に変換します（意訳）。
    input のときは、コミット時に CRLF を LF に変換し、チェックアウト時は行末を変更しません（意訳）。

（上記は実際の文章を短く意訳したものです。原文は git-config の core.autocrlf の項を参照してください）

動作を整理すると次の通りです。

  • core.autocrlf = true
    • コミット時: 作業ツリーの CRLF を LF に変換してからリポジトリに保存
    • チェックアウト時: リポジトリにある LF を CRLF に変換して作業ツリーに展開
  • core.autocrlf = input
    • コミット時: 作業ツリーの CRLF を LF に変換してから保存
    • チェックアウト時: 変換なし（リポジトリに入っているものをそのまま出す）
  • core.autocrlf = false（または未設定）
    • コミット時 / チェックアウト時: 行末変換を行わない

ポイントは：

  • true : 「Windows で作業している人向けに、作業ツリーは CRLF、リポジトリは LF で揃える」動き
  • input : 「作業ツリーは自分で好きにする / CRLF が混じっていたらコミット時に LF に直す」動き

4. .gitattributes の text / text=auto と core.autocrlf の関係

4.1 text 属性の意味

公式の gitattributes ドキュメントでは、text 属性について次のように書かれています。

つまり、text を付けると、

  • インデックスに登録するときに LF に正規化
  • チェックアウト時には、設定に応じて LF / CRLF に変換

といった、行末変換の対象になる「テキストファイル」だと明示する役割を持ちます。

4.2 text=auto の意味

同じドキュメントに text=auto についても説明があります。

text が "auto" のとき、Git がそのファイルがテキストかバイナリかを判定し、テキストであれば行末変換を行う（意訳）。
text が指定されていない場合、Git は core.autocrlf の設定を使って変換を行うかどうかを決める（意訳）。

ここから分かることは：

  • * text=auto を書くと、「これはテキストかもしれない」と Git に判断させる。
  • そのうえで、変換方法自体は core.autocrlf や eol 属性にしたがう。

4.3 .gitattributes による LF 正規化の公式な例

同じページには次のような例もあります。

すべてのテキストファイルの行末を正規化したい場合、* text=auto を設定し、git add --renormalize . を実行する（意訳）。

これが、リポジトリ内は LF に揃えたいときに、Git 公式ドキュメントでも紹介されている代表的なやり方です。
（※ 他にも、core.autocrlf=false を全環境で使い、.gitattributes だけで改行コードを管理する流儀も現実に存在します。その場合も、最終的には「リポジトリ内は LF に正規化する」ことが多く、この章で説明した考え方自体は共通です。）

5. 今回整理する 2×2 パターン

ここから先は、次の 2 軸で状況を分けて整理します。

軸 1: プロジェクトの性格 a) / b)

  • a) Linux ベースで開発する方が自然なケース
  • b) Windows ベースで開発する方が自然なケース

軸 2: どの環境の Git でそのリポジトリを開発するか

  • パターン 1: プロジェクトの性格にとって「素直な側」だけで開発する
    • a) のプロジェクトなら WSL2 側の Git だけで開発する（Linux 側で完結）
    • b) のプロジェクトなら Windows 側の Git（Git Bash 等）だけで開発する（Windows 側で完結）
  • パターン 2: 組織ルールや運用上の理由で、Windows 側の Git（Git Bash 等）だけで開発を完結させるパターン
    （例：WSL2 の利用が禁止されている / 推奨されていない現場で、Linux ベースのプロジェクトでも Git Bash 一択になるケース）

したがって、考えるべき組み合わせは 4 パターンです。

  1. パターン 1 + a) : Linux ベースのプロジェクトを、WSL2 側の Git だけで開発する（作業ツリーもリポジトリも LF）
  2. パターン 1 + b) : Windows ベースのプロジェクトを、Windows 側の Git だけで開発する（作業ツリーは CRLF、リポジトリは LF）
  3. パターン 2 + a) : Linux ベースのプロジェクトだが、組織ルールなどにより WSL2 が使えず、Windows 側の Git（Git Bash 等）だけで開発する（作業ツリーは CRLF、リポジトリは LF）
  4. パターン 2 + b) : Windows ベースのプロジェクトを、Windows 側の Git（Git Bash 等）だけで開発する（作業ツリーは CRLF、リポジトリは LF）

6. 今回のおすすめ設定（結論）

注意: ここで示す構成は、GitHub 公式ドキュメントなどでも紹介されている「Windows では core.autocrlf=true、Linux / macOS / WSL2 では core.autocrlf=input、リポジトリ側では .gitattributes で * text=auto を指定して LF に正規化する」という流儀に沿った「一例」です。
他にも、全環境で core.autocrlf=false にして、.gitattributes のみで改行コードを統一管理する流儀もあります。
本記事では「WSL2 + Git for Windows が混在する個人開発 / 小規模チーム」を想定し、運用しやすさの観点からこの構成を おすすめ構成 として採用しています。

この記事で前提とするおすすめ設定をあらためてまとめます。

6.1 設定内容

1) WSL2 側 Git

git config --global core.autocrlf input

2) Windows Git Bash 側 Git（Git for Windows）

git config --global core.autocrlf true

3) 各リポジトリのルートに .gitattributes

* text=auto

1)、2) の目的としては、各環境の作業ツリーの改行コードを「WSL2 側は LF、Windows Git Bash 側は CRLF」にしつつ、コミット時にはどちらも自動的に LF に直してからリポジトリに保存させるためです。

3) の目的としては、開発者それぞれの core.autocrlf 設定に関係なく、リポジトリ内のテキストファイルの改行コードを LF 一択に統一するためです。

6.2 なぜこの組み合わせなのか（ざっくり）

  • リポジトリの中身（Git が保管する内容）は、常に LF に正規化される。
  • a) のプロジェクトでも b) のプロジェクトでも、Git リポジトリという視点では「LF で揃える」ことがシンプルで安全。
  • WSL2（Linux）の作業ツリーは基本 LF、Windows の作業ツリーは CRLF でも LF でもよいが、
    • Windows 側は core.autocrlf=true にしておけば 多くの Windows ツールとの相性が良い CRLF になる。
    • WSL2 側は input にしておけば、もし CRLF が紛れ込んでも コミット時に LF に直してくれる。

ここから先は、これを 4 パターンに当てはめて、具体的にどう振る舞うかを見ていきます。

7. 4 パターン別の挙動と考え方

7.1 パターン 1 + a)（Linux ベースのプロジェクトを WSL2 の Git だけで触る）

  • 対象: Laravel / Rails / Django / React / Next.js / NestJS など、a) のプロジェクト
  • Git を触るのは WSL2 の Git だけ。Windows Git Bash 側の Git は同じリポジトリに対して使わない。

この場合：

  • .gitattributes の * text=auto により、テキストファイルは インデックスでは常に LF に正規化。
  • core.autocrlf=input により、万が一 CRLF が入り込んだ場合でも コミット時に LF に変換。
  • チェックアウト時は変換しないので、**作業ツリーの行末は「ファイルが持っているまま」**ですが、通常は LF になります。

ポイント

  • a) のプロジェクトで、本番も Docker も Linux なので、WSL2 側の作業ツリーが LF であることと相性が良い。
  • わざわざ CRLF を使う理由がないので、VSCode などのエディタも「LF 固定」で構わない。

7.2 パターン 1 + b)（Windows ベースのプロジェクトを Windows 側の Git だけで開発する）

  • 対象: b) のプロジェクト（C# / Windows アプリなど）
  • Git を触るのは Windows 側の Git（Git Bash / VSCode 組み込み Git / GitKraken など）だけ。WSL2 側の Git は同じリポジトリに対して使わない。

この場合も、リポジトリの中身は常に LF 正規化です。

  • .gitattributes の * text=auto により、テキストファイルはインデックスでは常に LF に揃う。
  • Windows 側の core.autocrlf=true により、チェックアウト時に LF → CRLF に変換されて作業ツリーに展開される。
  • コミット時には CRLF → LF に戻されてからリポジトリに保存される。

つまり：

  • Git 資産（リポジトリ内）は LF 固定
  • ローカルの作業ツリー（Windows 上で開くファイル）は CRLF

という状態になります。

b) のプロジェクトでは最終的な実行環境も Windows であることが多く、エディタや一部ツールは依然として CRLF を前提としている場合があります。
そのため、

  • 「リポジトリは LF で揃えつつ」
  • 「Windows 上での作業は CRLF で違和感なく行う」

というバランスをとるパターンが、パターン 1 + b) です。

7.3 パターン 2 + a)（Linux ベースのプロジェクトだが、Windows 側の Git だけで開発する）

ここが質問で強調されていた 「Windows + a)（Linux ベースなのに Git Bash で開発するケース）」 そのものです。

  • 対象: a) のプロジェクト（本来は Linux / WSL2 側で開発した方が自然なもの）
  • しかし組織ルールや運用上の理由で、Git を触るのは Windows 側の Git（Git Bash / VSCode 組み込み Git / GitKraken など）だけ。
    WSL2 側の Git は同じリポジトリに対して使わない前提です。

このときの挙動は、技術的には 7.2（パターン 1 + b）と同じ になります。

  1. リポジトリ内（Git が保存する中身）

    • .gitattributes の * text=auto により、テキストファイルはインデックスでは常に LF に正規化。
    • どのファイルも、コミットされた時点では LF のみになります。

  2. Windows 側の作業ツリー

    • core.autocrlf=true により、チェックアウト時に LF → CRLF 変換されて展開される。
    • コミット時には CRLF → LF に戻されてからリポジトリに保存される。

つまり：

  • Git 資産（リポジトリ内）は常に LF 固定
  • ローカルの作業ツリー（Windows 上で開くファイル）は CRLF

という構成です。

違いはあくまで「プロジェクトの性格」です。

  • a) のプロジェクトなので、最終的な実行環境は Linux / コンテナ / クラウド上の Linux などであることが多い。
  • それでも、Node.js / Python / PHP / Ruby など多くのランタイムは CRLF をそのまま受け入れて動くため、
    • 「編集時は CRLF でも実行時には LF ベースの世界で動く」
    • という構成で、実務上は問題なく回ることが多いです。

ただし、シェルスクリプト（.sh）だけは少し注意が必要です。

Linux では、deploy.sh のようなスクリプトを実行するときに

  • 実行ビット（chmod +x deploy.sh）が立っていること
  • 行末が LF のみであること

を前提にしています。ここに CRLF が混ざると、

  • bash: ./deploy.sh: /bin/bash^M: bad interpreter: No such file or directory

のような、原因が分かりにくいエラーになりがちです。

そのため、.sh だけは例えば次のようにしておくと安全です。

  • .gitattributes に「*.sh text eol=lf」を追加して、シェルスクリプトだけ必ず LF でコミットさせる
    当記事としては、 * text=auto も必要なため

    * text=auto
*.sh text eol=lf

    上記のような順序性で記述するのは、下記に基づいているからです。
    https://git-scm.com/docs/gitattributes

    When more than one pattern matches the path, a later line overrides an earlier line. This overriding is done per attribute.
    日本語訳)
    パスに複数のパターンが一致する場合、後の行が前の行を上書きします。この上書きは属性ごとに行われます

  • あるいは、.sh の編集・作成は WSL2 側（LF 前提の環境）で行い、CRLF が紛れ込まないようにする

こうしておくと、「アプリ本体は CRLF でも問題ないが、シェルスクリプトだけは LF 必須」という現場でもトラブルをかなり減らせます。

7.4 パターン 2 + b)（Windows ベースのプロジェクトを Windows 側の Git だけで開発する）

  • 対象: b) のプロジェクト（C# / Windows デスクトップアプリなど）
  • Git を触るのは Windows 側の Git（Git Bash / VSCode 組み込み Git / GitKraken など）だけ。
    パターン 1 + b) と同様に、WSL2 側の Git は同じリポジトリには使わない前提です。

技術的な挙動は 7.2（パターン 1 + b）と完全に同じです。

  • .gitattributes の * text=auto により、リポジトリ内のテキストファイルは常に LF に正規化される。
  • Windows 側の core.autocrlf=true により、作業ツリーでは CRLF として展開される。
  • コミット時には CRLF → LF に戻されて保存される。

つまり：

  • Git 資産（リポジトリ内）は LF 固定
  • ローカルの作業ツリーは CRLF

という構成になります。

パターン 2 + b) をあえて独立させているのは、

  • 「組織的に WSL2 を使わず、すべて Windows 側の Git で統一したい」
  • という運用方針のもとで b) のプロジェクトを扱う場面を切り分けて説明するためです。

技術的な意味では 7.2 と同じ挙動であり、設定とトラブルシュートの観点では 7.2 を見れば十分と考えて構いません。

8. sakura エディタ等での \r\n → \n 全置換は必要か？ やってはいけないか？

前提となる設定は繰り返しになりますが：

  • WSL2 側 Git : core.autocrlf=input
  • Windows Git Bash 側 Git : core.autocrlf=true
  • .gitattributes : * text=auto

この前提で考えます。

8.1 WSL2 側（Linux）の場合

  • 作業ツリーは基本 LF です。
  • もし何らかの理由で CRLF が混じっても、
    • コミット時に input が効いて LF に変換されてから保存されます。
  • .gitattributes により、テキストファイルは常に LF に正規化されます。

結論（WSL2 側）

  • sakura エディタの正規表現で わざわざ \r\n → \n に全置換する必要は基本的にありません。
  • どうしても気持ち悪ければ置換しても構いませんが、
    • Git の仕組みとしては 置換しなくても最終的には LF に揃うようになっています。

8.2 Windows 側（Git Bash / Git for Windows）の場合

  • core.autocrlf=true なので、チェックアウト時に LF → CRLF 変換されます。
  • コミット時には CRLF → LF 変換されてからリポジトリに保存されます。

この状態で、sakura エディタなどで：

  • \r\n → \n に変換して保存したファイルをコミットすると、
    • その時点では作業ツリーは LF だけになっています。
    • コミットされる内容は当然 LF です。
  • しかし、次に git checkout などを行うと、
    • core.autocrlf=true の動作により、再び CRLF に変換されてチェックアウトされます。

結論（Windows 側）

  • \r\n → \n に全置換すること自体は 禁止ではありませんが、あまり意味がありません。
  • 次のチェックアウトでまた CRLF になりますし、
    • 場合によっては差分がややこしくなったり、core.safecrlf を true にしていると警告が出ることがあります。
  • したがって、Windows 側では、行末は Git に任せておき、わざわざ手で LF に揃える必要はない、というのが実務的な結論です。

9. Git for Windows インストーラーと core.autocrlf の対応

Git for Windows のセットアップウィザードには、行末コードに関する 3 つの選択肢があります（日本語訳ベースで表現します）。

インストーラーの選択肢と core.autocrlf の対応は次の通りです。

  1. 「チェックアウト時に Windows スタイル（CRLF）、コミット時に Unix スタイル（LF）」
    → core.autocrlf = true

  2. 「チェックアウトはそのまま、コミット時に Unix スタイル（LF）」
    → core.autocrlf = input

  3. 「チェックアウトもコミットも変換しない」
    → core.autocrlf = false

インストール直後に、実際の値は次のコマンドで確認できます。

git config --global core.autocrlf

この記事で前提にしている Windows 側 Git Bash では trueという状態にするには：

  • Git for Windows インストール時に「チェックアウトは Windows スタイル、コミットは Unix スタイル」を選ぶ
    もしくは

  • 既にインストール済みであれば、次を実行する：

    git config --global core.autocrlf true

10. まとめ

最後に、この記事のポイントを整理します。

  1. プロジェクトの性格を

    • a) Linux ベースで開発する方が自然なケース
    • b) Windows ベースで開発する方が自然なケース
      という 2 パターンに分けて考えた。

  2. Git の行末変換は

    • core.autocrlf（設定全体）
    • .gitattributes の text / text=auto
      の 2 枚看板で制御される。

  3. .gitattributes に * text=auto を書くと、

    • 「テキストファイルは LF に正規化しつつ、作業ツリーの行末はプラットフォームや設定に従って CRLF / LF を選べる」
      という、公式が推奨する運用ができる。

  4. 今回のおすすめ構成：

    1) WSL2 側 Git

    git config --global core.autocrlf input

    2) Windows Git Bash 側 Git（Git for Windows）

    git config --global core.autocrlf true

    3) 各リポジトリのルートに .gitattributes

    * text=auto

    1)、2) の目的としては、各環境の作業ツリーの改行コードを「WSL2 側は LF、Windows Git Bash 側は CRLF」にしつつ、コミット時にはどちらも自動的に LF に直してからリポジトリに保存させるためです。

    3) の目的としては、開発者それぞれの core.autocrlf 設定に関係なく、リポジトリ内のテキストファイルの改行コードを LF 一択に統一するためです。

  5. この構成にすると：

    • リポジトリの中身は常に LF で正規化される。
    • WSL2 側から見ると、Linux プロジェクトとして自然な LF の世界になる。
    • Windows 側から見ると、作業ツリーは CRLF なので、多くの Windows ツールと相性が良い。

  6. a) / b)、WSL2 / Git Bash の 4 パターンすべてで、

    • 「リポジトリは LF で揃える」
    • 「各環境の作業ツリーは、その環境にとって都合の良い行末を使う」
      という方針で矛盾なく整理できる。

  7. sakura エディタ等での \r\n → \n 全置換については、

    • WSL2 側ではそもそも LF が基本なので、必要ない。
    • Windows 側では core.autocrlf=true により次のチェックアウト時に CRLF に戻るため、わざわざ全置換する意味は薄い。

以上が、core.autocrlf と .gitattributes（* text=auto）を組み合わせたときの挙動と、その理由付けの整理です。

Discussion