web-dev-qa-db-ja.com

Git on Windows：crlf設定とはどういう意味ですか？

GitのCrLf設定に関連する複雑さを理解していません：core.autocrlf、core.safecrlf

私はチームでクロスプラットフォームプロジェクトを開発しており、WindowsとLinuxの両方の開発者が、行末スタイルのためにファイルを変更済みとしてgitにマークせずに一緒に作業できるようにしたいと考えています。

さまざまな設定はどういう意味ですか？オプションを選択すると、どのような結果になりますか？そして、私の場合の最良の解決策は何でしょうか？

はい、私は この質問 に気づいており、そこの答えは洞察力に欠けていたため、役に立たなかった。

windowslinuxgitnewlinecore.autocrlf
69
Jonathan

autocrlfの3つの値：

  • true-コンテンツがリポジトリに入る（コミットされる）と、その行末がLFに変換され、コンテンツがリポジトリから出る（チェックアウトされる）と、行末がCRLFに変換されます。これは一般に、無知なWindowsユーザー/エディター向けです。エディター（またはユーザー）がCRLFで終わるファイルを作成し、通常のLFで終わるが、望むLFリポジトリの末尾、これはあなたをカバーすることを望みますが、物事がおかしくなる可能性がありますが、リンクされた質問に偽のマージ競合と変更されたファイルのレポートの例があります。

  • input-コンテンツがリポジトリに入ると、その行末はLFに変換されますが、途中でコンテンツはそのまま残されます。これは基本的にtrueと同じ領域にあり、エディターが実際にLFエンディングを正しく処理できるという前提で、誤って作成する可能性を防止しているだけです。 CRLFで終わるファイル。

  • false-gitは行末をまったく処理しません。それはあなた次第です。これは多くの人が推奨するものです。この設定を使用すると、ファイルの行末が乱れそうになった場合、そのことに注意する必要があります。そのため、マージの競合が発生する可能性はかなり低くなります（情報に基づいたユーザーを想定）。エディター/ IDEの使用方法について開発者を教育することで、ほとんどの問題を処理できます。プログラマー向けに設計したすべてのエディターは、適切に構成されていればこれに対処できます。

autocrlfは、リポジトリ内のalreadyのコンテンツには影響しないことに注意してください。以前にCRLFエンディングで何かをコミットしたことがある場合は、そのままです。これは、autocrlfに依存しないようにする非常に良い理由です。 1人のユーザーがそれを設定していない場合、CRLFで終わるコンテンツをレポに取得できます。正規化を強制するより強力な方法は、 テキスト属性 ;与えられたパスのautoに設定すると、gitがコンテンツをバイナリ（バイナリではなく）に決定すると仮定して、行末の正規化のためにマークします。

関連するオプションはsafecrlfです。これは基本的に、バイナリファイルに対してCRLF変換を不可逆的に実行しないようにするための単なる方法です。

私はWindowsの問題やgitを扱った経験が豊富ではないので、その意味/落とし穴についてのフィードバックを歓迎します。

94
Cascabel

コミットおよびチェックアウトの場合に考えられる3つの値を調査しましたが、これが結果の表です。

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => LF     ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║  git checkout ║ LF => LF     ║ LF => LF     ║ LF => CRLF   ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

すべてのプラットフォームでcore.autocrlf = inputを使用することをお勧めします。この場合、GitがCRLFに直面すると、暗黙的にLFに変換され、LFを持つ既存のファイルはそのまま残ります。

9
pratt

参考までに、デフォルトでは、Windowsで終わる行はCRLFを取り、LinuxはLFを取ります。明確な理解のために以下の表を見つけてください。

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║    false     ║    input     ║    true      ║
║               ║ Win => Unix  ║ Win => Unix  ║ Win => Unix  ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => LF     ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ *CRLF => LF  ║ *CRLF => LF  ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║  git checkout ║ LF => LF     ║ LF => LF     ║ *LF => CRLF  ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

上記の表情報では、記号*はWindowsとUnixの違いを強調しています。以下に、OSプラットフォームに基づいたCLRF情報を示します。

Windowsユーザーの場合

  • Windowsユーザーがクロスプラットフォームプロジェクトで作業している場合、It [〜＃〜] must [〜＃〜] be core.autocrlf=true Windowsマシンおよびcore.autocrlf=input Unixマシン用。
  • WindowsユーザーがWindowsプロジェクトのみで作業する場合、両方のcore.autocrlf=trueまたはcore.autocrlf=false。だが core.autocrlf=inputこの場合、問題が発生します。

Unixユーザーの場合（Linux/Mac OS）

  • Unixユーザーがクロスプラットフォームプロジェクトで作業している場合、It [〜＃〜] must [〜＃〜] be core.autocrlf=true Windowsマシンおよびcore.autocrlf=input Unixマシン用。
  • UnixユーザーがUnixプロジェクトのみで作業する場合、両方のcore.autocrlf=inputまたはcore.autocrlf=false。だが core.autocrlf=trueこの場合、問題が発生します。

同じOSユーザーの場合

  • 純粋なWindowsプロジェクトまたは純粋なUnixプロジェクトの場合、core.autocrlf=false。
3
Srikanth Popuri