650

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

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

CRLF の行末を適切に処理するには?

4

9 に答える 9

811

この質問をしてからほぼ 4 年後、私はついに完全に満足できる答えを見つけました。

詳細については、github:helpの行末の処理に関するガイドを 参照してください。

Git では、 ファイルのtext 属性を直接使用して、リポジトリの行末プロパティを設定でき.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ます。同意すると、アプリはリポジトリ内のすべてのファイルの正規化も実行します。

最後に、Mind the End of Your Line の記事では、より多くの背景を提供し、目前の問題で Git がどのように進化したかを説明しています。これは必読だと思います。

チーム内に EGit または JGit (Eclipse や TeamCity などのツールが使用) を使用して変更をコミットするユーザーがいる可能性があります。@gatinueta がこの回答のコメントで説明したように、あなたは運が悪いです:

チームに Egit または JGit を使用する人がいる場合、この設定では完全には満足できません。これらのツールは .gitattributes を無視し、喜んで CRLF ファイルhttps://bugs.eclipse.org/bugs/show_bug.cgi? id=342372

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

ソフトウェアは簡単だと誰が言いましたか? :-/

于 2012-06-01T18:56:35.800 に答える
127

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

于 2008-10-04T20:42:06.417 に答える
83

autocrlf=input自分が何をしているのかを本当に理解していない限り、ほとんどの場合、それを望んでいます。

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

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

上記の段落は、もともと gmane.org のスレッドから引っ張ってきたものですが、その後ダウンしました。

于 2009-07-10T22:36:55.893 に答える
60

混合環境 (Microsoft + Linux + Mac) で行末について一貫性を持たせるための 2 つの代替戦略:

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

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

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

  2. Linux/UNIX またはMS Windows (リポジトリまたはグローバル)に設定core.autocrlfします。inputtrue

    git config --global core.autocrlf input

  3. オプションで、(to stop) または(to sing:) に設定core.safecrlfして、逆改行変換が同じファイルになるかどうかを比較する追加のガードを追加しますtruewarn

    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 変数の詳細

于 2012-06-26T01:18:10.747 に答える
11

を使用すると、 Visual Studio 2010プロジェクトcore.autocrlf=falseでファイルをチェックアウトするとすぐに、すべてのファイルが更新済みとしてマークされるのを停止しました。開発チームの他の2人のメンバーもWindowsシステムを使用しているため、混合環境は機能しませんでしたが、リポジトリに付属のデフォルト設定では、クローン作成直後にすべてのファイルが常に更新済みとしてマークされていました。

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

20年以上経った今でも、OS間のラインエンドの不一致に取り組んでいます...悲しい。

于 2011-03-16T03:10:52.540 に答える
10

core.autocrlf構成オプションをに設定してみてくださいtrue。core.safecrlfオプションもご覧ください。

実際には、リポジトリにすでに設定されているように聞こえcore.safecrlfます。理由は次のとおりです。

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

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

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

于 2008-10-05T03:50:12.263 に答える
7

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

* テキスト = 自動

レポの.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.
于 2016-02-14T23:02:41.947 に答える
5

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

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

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

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

私の解決策：

Windows-Machines: すべてをそのままにします。あなたはデフォルトの Windows '一匹オオカミ' 開発者であり、次のように処理する必要があるため、何も気にする必要はありません。

Unix マシン

  1. config の[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
于 2013-03-20T15:21:31.623 に答える