CRLFで終わる行でファイルをコミットしようとしましたが、失敗しました。

私は一日中Windowsコンピューターでさまざまな戦略を試すことに費やしましたが、Gitの使用をやめ、代わりにMercurialを試してみることに夢中になりました。

回答ごとに1つのベストプラクティスのみを共有してください。

この質問をしてからほぼ4年後、ようやく私は完全に満足する答えを見つけました！

詳細については、github：helpの「行末の処理」ガイドを ご覧ください。

Gitでは、 ファイルのテキスト属性を直接使用して、リポジトリの行末プロパティを設定でき.gitattributesます。このファイルはリポジトリにコミットされ、core.autocrlf設定を上書きするため、git設定に関係なく、すべてのユーザーに一貫した動作を保証できます。

したがって

これの利点は、ラインの終わりの構成がリポジトリと一緒に移動するようになり、共同編集者が適切なグローバル設定を持っているかどうかを心配する必要がないことです。

これは.gitattributesファイルの例です

# Auto detect text files and perform LF normalization
*        text=auto

*.cs     text diff=csharp
*.java   text diff=java
*.html   text diff=html
*.css    text
*.js     text
*.sql    text

*.csproj text merge=union
*.sln    text merge=union eol=crlf

*.docx   diff=astextplain
*.DOCX   diff=astextplain

# absolute paths are ok, as are globs
/**/postinst* text eol=lf

# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf

最も人気のあるプログラミング言語用のすぐに使える.gitattributesファイルの便利なコレクションがあります。始めるのに便利です。

を作成または調整したら.gitattributes、一度限りの行末再正規化を実行する必要があります。

アプリでプロジェクトのGitリポジトリを開いた後、GitHubデスクトップアプリが.gitattributesファイルを提案して作成できることに注意してください。試すには、右上隅にある歯車のアイコン> [リポジトリ設定...]> [行末と属性]をクリックします。推奨を追加するように求められ.gitattributesます。同意すると、アプリはリポジトリ内のすべてのファイルの正規化も実行します。

最後に、マインド・ザ・エンド・オブ・ユア・ラインの記事は、より多くの背景を提供し、Gitが現在の問題でどのように進化したかを説明しています。これは必読だと思います。

おそらく、チームのユーザーがEGitまたはJGit（EclipseやTeamCityなどのツールを使用）を使用して変更をコミットしているはずです。次に、@ gatinuetaがこの回答のコメントで説明したように、あなたは運が悪いです。

チームでEgitまたはJGitを使用している場合、これらのツールは.gitattributesを無視し、CRLFファイルhttps://bugs.eclipse.org/bugs/show_bug.cgi？ id = 342372

1つのトリックは、別のクライアントで変更をコミットさせることかもしれません、とSourceTreeは言います。私たちのチームは当時、多くのユースケースでEclipseのEGitよりもそのツールを好みました。

ソフトウェアは簡単だと誰が言ったのですか？：-/

行末を変換しません。データを解釈するのはVCSの仕事ではなく、単に保存してバージョン管理するだけです。現代のすべてのテキストエディターは、とにかく両方の種類の行末を読み取ることができます。

autocrlf=input自分が何をしているか本当に理解していない限り、たいていの場合は欲しがります。

以下の追加のコンテキスト：

core.autocrlf=trueDOSで終了するのが好きな場合か、core.autocrlf=inputunix-newlinesを好む場合のどちらかになります。どちらの場合も、GitリポジトリにはLFのみがあり、これは正しいことです。の唯一の議論core.autocrlf=falseは、自動ヒューリスティックが一部のバイナリをテキストとして誤って検出し、タイルが破損する可能性があることでした。その core.safecrlfため、元に戻せない変更が発生した場合にユーザーに警告するオプションが導入されました。実際、元に戻せない変更には2つの可能性があります-テキストファイルの行末が混在しているため、この正規化が望ましいため、この警告は無視できます。または、Gitがバイナリファイルをテキストとして誤って検出した可能性もあります。次に、属性を使用して、このファイルがバイナリであることをGitに通知する必要があります。

上記の段落は、もともとgmane.orgのスレッドから抜粋されたものですが、それ以降は削除されています。

混合環境（Microsoft + Linux + Mac）で行末を一貫させるための 2つの代替戦略：

A. すべてのリポジトリ設定ごとにグローバル

1）すべてを1つの形式に変換する

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2）に設定core.autocrlfするinputのLinux / UNIX上またはtrue）MS Windows上で（リポジトリまたはグローバル

git config --global core.autocrlf input

3）[オプション]を設定core.safecrlfするtrue）を停止（またはwarn（逆改行変換が同じファイルをもたらす場合に比較し、余分なガードを追加する:)歌います

git config --global core.safecrlf true

B.またはリポジトリごとの設定

1）すべてを1つの形式に変換する

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2）.gitattributesリポジトリにファイルを追加する

echo "* text=auto" > .gitattributes
git add .gitattributes
git commit -m 'adding .gitattributes for unified line-ending'

バイナリファイルについて心配する必要はありません-Gitは十分に賢いはずです。

safecrlf / autocrlf変数の詳細

core.autocrlf設定オプションをに設定してみてくださいtrue。また、見ていcore.safecrlfオプションを選択します。

実際にcore.safecrlfは、リポジトリにすでに設定されている可能性があります。

これがcore.autocrlfの現在の設定に当てはまらない場合、gitはファイルを拒否します。

この場合は、テキストエディターが行末を一貫して使用するように構成されていることを確認する必要があります。テキストファイルにLFとCRLFの行末が混在している場合、問題が発生する可能性があります。

最後に、Windowsで単に「与えられたものを使用する」こととLFで終了する行を使用することの推奨は、それが解決する以上の問題を引き起こすと感じています。Gitには、行末を賢明な方法で処理しようとする上記のオプションがあるため、それらを使用することは理にかなっています。

使用してcore.autocrlf=false、私は私の中でそれらをチェックアウトするとすぐに更新マークされることから、すべてのファイルを停止したのVisual Studio 2010のプロジェクト。開発チームの他の2人のメンバーもWindowsシステムを使用しているため、混合環境は機能しませんでした。

肝心なのは、ご使用の環境に適したCRLF設定を見つけることです。特に、Linuxボックス上の他の多くのリポジトリでは、autocrlf = trueより良い結果が得られます。

20年以上経った今でも、OS間の行末格差に対処しています...悲しいです。

これらは、MacまたはLinuxユーザーとコードを共有するWindowsおよびVisual Studioユーザー向けの2つのオプションです。詳細な説明については、gitattributesのマニュアルをご覧ください。

* text = auto

レポの.gitattributesファイルに次を追加します。

*   text=auto

これLFにより、リポジトリ内の行末ですべてのファイルが正規化されます。

また、オペレーティングシステム（core.eol設定）に応じて、作業ツリー内のファイルは、LFUnixベースのシステムまたはCRLFWindowsシステム用に正規化されます。

これは、Microsoft .NETリポジトリが使用する構成です。

例：

Hello\r\nWorld

常にリポジトリとして正規化されます：

Hello\nWorld

チェックアウト時に、Windowsの作業ツリーは次のように変換されます。

Hello\r\nWorld

チェックアウト時に、Macの作業ツリーは次のようになります。

Hello\nWorld

注：リポジトリに正規化されていないファイルが既に含まれている場合、git statusこれらのファイルは、次に変更を加えたときに完全に変更されたものとして表示されます。他のユーザーが後で変更をマージするのは面倒です。詳細については、行末を変更した後のリポジトリの更新を参照してください。

core.autocrlf = true

ファイルでtextが指定されていない場合.gitattributes、Gitはcore.autocrlf設定変数を使用して、ファイルを変換する必要があるかどうかを判断します。

Windowsユーザーにとってgit config --global core.autocrlf trueは、次の理由から優れたオプションです。

• ファイルは、リポジトリに追加されたときにのみLF行末に正規化されます。リポジトリで正規化されていないファイルがある場合、この設定はそれらに影響しません。
• すべてのテキストファイルはCRLF、作業ディレクトリの行末に変換されます。

このアプローチの問題は次のとおりです。

• を使用しているWindowsユーザーの場合は、行末がautocrlf = input付いた一連のファイルが表示されますLF。コミットはLF行末で正常化されるため、チームの他のメンバーにとって危険ではありません。
• を使用しているWindowsユーザーの場合は、行末がcore.autocrlf = false付いた一連のファイルが表示され、行末がLF付いたファイルをCRLFリポジトリに導入できます。
• ほとんどのMacユーザーはautocrlf = input、CRLFファイル名の末尾が付いたファイルを使用して取得する可能性がありますcore.autocrlf = false。

--- UPDATE 3 ---（UPDATE 2と競合しません）

WindowsユーザーがテキストファイルでのCRLF作業を好み、linux / macユーザーLFがテキストファイルでの作業を好む場合を考慮してください。リポジトリのメンテナーの観点から答えを提供する：

私にとって最良の戦略（解決する問題が少ない）は、Windowsのみのプロジェクトで作業している場合でも、すべてのテキストファイルをLFgitリポジトリ内に保持することです。次に、コミットのためにファイルをステージングする際に戦略（リポジトリ上のLF）を尊重するプロパティ値を選択することを条件として、クライアントに好みの行末スタイルで作業する自由を与えます。core.autocrlf

ステージングは、改行戦略がどのように機能するかを理解しようとするときに多くの人々が混乱させるものです。プロパティの正しい値を選択する前に、次の点を理解することが不可欠です。core.autocrlf

• コミット用のテキストファイルの追加（ステージング）は、ファイルを.git/サブディレクトリ内の別の場所にコピーし、変換された行末で（core.autocrlfクライアント構成の値に応じて）するようなものです。これはすべてローカルで行われます。
• 設定core.autocrlfは、質問に対する回答を提供するようなものです（すべてのOSでまったく同じ質問です）。
  • 「git-client は 、リモートからレポジトリの変更をチェックアウト（プル）するときにLFからCRLFに変換する必要がありますか、またはb。 コミットするファイルを追加するときにCRLFからLFに変換しますか？」と可能な回答（値）次のとおりです。
  • false:" 上記のいずれも実行しない "、
  • input:「bだけを行う」
  • true：「やるとaとb」
  • 「しない」だけがあることに注意してください

幸いにも

• git client defaults（windows：core.autocrlf: true、linux / mac：） core.autocrlf: falseはLF-only-repo戦略と互換性があります。
  意味：Windowsクライアントはデフォルトで、リポジトリをチェックアウトするときにCRLFに変換し、コミットのために追加するときにLFに変換します。Linuxクライアントはデフォルトでは変換を行いません。これにより、理論的にはリポジトリのみが保持されます。

残念ながら：

• git core.autocrlf値を尊重しないGUIクライアントがある可能性があります
• 値を使用してlf-repo戦略を尊重しない人がいるかもしれません。たとえばcore.autocrlf=false、コミットのためにCRLFを使用してファイルを追加します。

できるだけ早く非LFテキストファイルを検出するために、上記クライアントによってコミット ---あなたがアップデート2 ---に記述されているものをフォローすることができます（git grep -I --files-with-matches --perl-regexp '\r' HEAD使用してコンパイルされたクライアント上：--with-libpcreフラグ）

そして、これが問題です。私はリポジトリのメンテナーとしてを保持しているgit.autocrlf=inputので、コミットのためにそれらを再度追加するだけで、誤ってコミットされたファイルを修正できます。そして、私は「間違ってコミットされたファイルを修正する」というコミットテキストを提供します。

限り.gitattributesconcearnedされます。それを理解していないUIクライアントが他にもあるので、私はそれを当てにしません。私はテキストファイルとバイナリファイルのヒントを提供するためにのみ使用し、どこでも同じ行末を保持する必要があるいくつかの例外的なファイルにフラグを立てます。

*.java          text !eol # Don't do auto-detection. Treat as text (don't set any eol rule. use client's)
*.jpg           -text     # Don't do auto-detection. Treat as binary
*.sh            text eol=lf # Don't do auto-detection. Treat as text. Checkout and add with eol=lf
*.bat           text eol=crlf # Treat as text. Checkout and add with eol=crlf

質問：しかし、なぜ改行処理戦略にまったく関心があるのですか？

回答：1文字の変更コミットを回避するには、変更を実行したクライアントがコミットする前にファイル全体をcrlfからlf（またはその逆）に自動変換したため、5000行の変更として表示されます。紛争の解決が関係している場合、これはかなり苦痛になる可能性があります。あるいは、それが不合理な対立の原因となる場合もあります。

---更新2 ---

ほとんどの場合、gitクライアントの障害が機能します。Windowsのみのクライアント、Linuxのみのクライアント、またはその両方がある場合でも、これらは：

• ウィンドウ： core.autocrlf=trueチェックアウト時に行をCRLFに変換し、ファイルを追加するときに行をLFに変換することを意味します。
• linux： core.autocrlf=inputチェックアウト時に行を変換せず（ファイルはLFでコミットされることが期待されているため必要ありません）、ファイルを追加するときに行をLFに変換します（必要な場合）。（-update3-：これはfalseデフォルトであるようですが、これでも問題ありません）

プロパティはさまざまなスコープで設定できます。--global最後に説明するIDEの問題を回避するために、スコープを明示的に設定することをお勧めします。

git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf

また、私は強くなり落胆使用してWindows上で git config --global core.autocrlf false（場合には、Windowsクライアントだけを持っている）に提案されたものとは対照的に gitのドキュメント。falseに設定すると、リポジトリにCRLFを持つファイルがコミットされます。しかし、本当に理由はありません。プロジェクトをLinuxユーザーと共有する必要があるかどうかは決してわかりません。さらに、デフォルトを使用する代わりに、プロジェクトに参加するクライアントごとに1つの追加ステップがあります。

ここで*.bat *.sh、LFまたはCRLFを使用してチェックアウトするファイルの特殊なケース（など）を使用できます。.gitattributes

まとめると、ベストプラクティスは次のとおりです。

• すべての非バイナリファイルがgit repoのLFでコミットされていることを確認してください（デフォルトの動作）。
• このコマンドを使用して、CRLFでファイルがコミットされていないことを確認します。git grep -I --files-with-matches --perl-regexp '\r' HEAD（注： Windowsクライアントgit-bashでは、Linuxクライアントでのみ機能し--with-libpcre、./configure）。
• 上記のコマンドを実行してそのようなファイルを見つけた場合は、それらを修正してください。これには（少なくともLinuxでは）以下が含まれます。
  • セットcore.autocrlf=input（--- update 3-）
  • ファイルを変更する
  • 変更を元に戻します（ファイルは変更されたものとして引き続き表示されます）
  • それをコミット
• 必要最小限のもののみを使用してください .gitattributes
• core.autocrlf上記の説明をデフォルト値に設定するようユーザーに指示します。
• の存在を100％に数えないでください.gitattributes。IDEのgit-clientsはそれらを無視するか、それらを別々に扱うかもしれません。

言ったようにgit属性にいくつか追加することができます：

# Always checkout with LF
*.sh            text eol=lf
# Always checkout with CRLF
*.bat           text eol=crlf

.gitattributesバイナリファイルの自動検出を使用する代わりに、他のいくつかの安全なオプションを考えます。

• -text（例：*.zipまたは*.jpgファイル：テキストとして扱われません。したがって、行末の変換は試行されません。変換プログラムを通じて差分が可能になる場合があります）
• text !eol（例：*.java、*.html：テキストとして扱われますが、eolスタイル設定が設定されていません。そのため、クライアント設定が使用されます。）
• -text -diff -merge（例*.hugefile：テキストとして扱われません。相違/マージはできません）

---以前の更新---

ファイルを誤ってコミットするクライアントの1つの痛みを伴う例：

netbeans 8.2（Windows上）は、明示的にglobal に設定していない限り、CRLFを含むすべてのテキストファイルを誤ってコミットします。これは、標準のgitクライアントの動作と矛盾し、更新/マージ中に後で多くの問題を引き起こします。これにより、元に戻した場合でも、一部の ファイルは異なるように見えます（そうではありません）。プロジェクトに 正しいものを追加した場合でも、netbeansで同じ動作が発生します。core.autocrlf
.gitattributes

コミット後に次のコマンドを使用すると、少なくとも、gitリポジトリに行末の問題があるかどうかを早期に検出できます。 git grep -I --files-with-matches --perl-regexp '\r' HEAD

私は何時間も費やして、の可能な限りの最善の使用法を考え出し.gitattributes、ついにそれを当てにすることができないことに気づきました。
残念ながら、JGitベースのエディターが存在する（.gitattributes正しく処理できない）限り、安全な解決策はエディターレベルでもどこでもLFを強制することです。

以下のanti-CRLF消毒剤を使用してください。

• Windows / Linuxクライアント： core.autocrlf=input

• コミット.gitattributes： * text=auto eol=lf

• コミット済み.editorconfig（http://editorconfig.org/）これは、標準化されたフォーマットの一種であり、エディタプラグインと組み合わされています。

  • https://github.com/editorconfig/
  • https://github.com/welovecoding/editorconfig-netbeans/

これは単なる回避策です。

通常は、gitに付属のソリューションを使用してください。これらはほとんどの場合にうまく機能します。.gitattributesを設定して、WindowsおよびUnixベースのシステムで開発を共有する場合は、強制的にLFにします。

私の場合、10人を超えるプログラマがWindowsでプロジェクトを開発していました。このプロジェクトはCRLFでチェックインされ、LFに強制するオプションはありませんでした。

一部の設定は、LF形式に影響を与えることなく、私のマシンで内部的に書き込まれました。したがって、一部のファイルは、小さなファイルの変更ごとにグローバルにLFに変更されました。

私の解決策：

Windows-Machines： すべてをそのままにします。あなたはデフォルトのWindowsの「オオカミ」開発者であり、次のように処理する必要があるため、何も気にしないでください。「広い世界に他のシステムはありませんよね？」

Unix-Machines

1. 次の行を構成の[alias]セクションに追加します。このコマンドは、すべての変更（つまり、変更/新規）ファイルをリストします。

   lc = "!f() { git status --porcelain \
                | egrep -r \"^(\?| ).\*\\(.[a-zA-Z])*\" \
                | cut -c 4- ; }; f "

2. これらの変更されたすべてのファイルをdos形式に変換します。

   unix2dos $(git lc)

3. オプションで...

   1. このアクションのgit フックを作成して、このプロセスを自動化します

   2. paramsを使用してインクルードし、grep特定のファイル名のみに一致するように関数を変更します。例：

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...

   3. 追加のショートカットを使用して、さらに便利にしてください。

      c2dos = "!f() { unix2dos $(git lc) ; }; f "

      ...と入力して、変換されたものを起動します

      git c2dos