WindowsでのGit。crlfの設定は何を意味するのか？

質問

gitのCrLf設定に関連する複雑なことがよくわかりません。 core.autocrlf , core.safecrlf

私はチームでクロスプラットフォームのプロジェクトを開発しており、WindowsとLinuxの両方の開発者が、行末のスタイルという理由だけでファイルを修正したとgitがマークすることなく、一緒に作業できるようにしたいと思っています。

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

はい、わかっています。 この質問 で、そこでの回答は洞察力に欠け、したがって役に立ちませんでした。

どのように解決するのですか？

の3つの値は autocrlf :

• true - コンテンツがリポジトリに入る（コミットされる）とき、その行末は LF に変換され、コンテンツがリポジトリから出る（チェックアウトされる）とき、その行末は CRLF に変換されます。これは一般的に、無知なWindowsユーザーやエディターのためのものです。エディター（またはユーザー）は CRLF 終わりのファイルを作成し、通常の LF 終わりのファイルを見るとパニックになりますが、リポジトリでは LF 終わりにしたい、という前提で考えると、これでうまくカバーできます。しかし、うまくいかないこともありえます。リンク先の質問には、偽のマージコンフリクトと変更されたファイルのレポートの例があります。

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

• false - git は改行コードを全く扱いません。あなた次第です。これは多くの人が推奨していることです。この設定では、ファイルの改行コードがいじられようとすると、それを意識しなければならなくなります。そのため、マージの衝突はかなり少なくなります（知識のあるユーザーを想定しています）。開発者にエディタ/IDEの使い方を教育することで、この問題はかなり解決されます。私が見てきたプログラマー向けに設計されたすべてのエディタは、適切に設定されていれば、これに対処することが可能です。

以下のことに注意してください。 autocrlf であるコンテンツには影響しません。 であるコンテンツには影響を与えません。 であるコンテンツには影響を与えません。もしあなたが以前に CRLF 末尾を持つものをコミットしたなら、それはそのまま残ります。これは autocrlf に依存しないようにする非常に良い理由です。あるユーザーがそれを設定していない場合、CRLF 終わりのコンテンツをリポジトリに取り込むことができ、それが残ってしまうからです。正規化を強制するもっと強力な方法は テキスト属性 に設定することです。 auto を設定すると、git がその内容を (バイナリではなく) テキストだと判断した場合に行末の正規化を行うためのマークが付けられます。

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

私は Windows の問題と git を扱った経験があまりないので、影響や落とし穴についてのフィードバックは確かに歓迎されます。