141

コマンドラインから次を見た後：

# On branch RB_3.0.10
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   index.htm

次のコマンドを入力して、変更を破棄しようとしています。

git checkout -- index.htm

しかし、git status を再実行すると、まったく同じように見えます。チェックアウトが機能していないようです。私は何か間違ったことをしていますか？Windows/cygwin で GIT 1.6.1.2 を使用しています。

# On branch RB_3.0.10
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   index.htm
4

23 に答える 23

44

これが私の経験です。次の変数を に設定します.git/config。

[core]
    autocrlf = false
    safecrlf = false
    eol = crlf

次に実行する$ git checkout HEAD .と、動作します。しかし、$ git checkout -- .そうではありません。

* git バージョン 1.9.3

于 2014-08-15T05:35:38.587 に答える
36

ファイルにはどのような変更がgit diff表示されますか? Windows では、このような問題を引き起こす行末の問題を見てきました。その場合は、 と の設定を確認してgit config core.autocrlfくださいgit config core.safecrlf。これらの設定に関するドキュメントはこちらにあります。

git svnSubversion との統合に使用している場合は、autocrlfがオフになっていることを確認してください。私が知る限り、この構成では壊れているだけであり、ほとんどのツールは、変更checkoutを元に戻すためにファイルが変更されたと認識します。

を実行したときに問題が発生しgit checkout、git statusファイルがまだ変更されてgit diffいることが示され、ファイル内のすべての行でファイルが変更されていることが示されている場合は、これが問題です。

core.autocrlf

true の場合、git は、ファイル システムから読み取るときにテキスト ファイルの行末の CRLF を LF に変換し、ファイル システムに書き込むときに逆に変換します。変数は入力に設定できます。この場合、変換はファイルシステムからの読み取り中にのみ発生しますが、ファイルは行末に LF で書き出されます。現在、どのパスが「テキスト」と見なされるか (つまり、autocrlf メカニズムの対象となるか) は、純粋にコンテンツに基づいて決定されます。

core.safecrlf

true の場合、core.autocrlf によって制御される CRLF の変換が元に戻せるかどうかを git がチェックします。Git は、コマンドが作業ツリー内のファイルを直接または間接的に変更するかどうかを確認します。たとえば、ファイルをコミットした後に同じファイルをチェックアウトすると、作業ツリーに元のファイルが生成されます。これが core.autocrlf の現在の設定に当てはまらない場合、git はファイルを拒否します。この変数は "warn" に設定できます。この場合、git は元に戻せない変換についてのみ警告しますが、操作は続行します。...

于 2009-10-15T23:47:27.510 に答える
24

合格する必要があると思います-f

man ページ ( man git-checkout、GIT-CHECKOUT(1)) から:

-f, --force
インデックスまたは作業ツリーが HEAD と異なっていても続行します。
これは、ローカルの変更を破棄するために使用されます。

たとえば、現在のブランチの変更を破棄して、別のブランチに切り替えます。

git checkout -f master
于 2009-10-19T02:14:34.430 に答える
14

@ 1800-information が示唆するように、それは行末である可能性がありますが、別の可能性は、ファイルモードの違い (チェックアウトコマンドでこれらのファイルを元に戻すことを妨げている) です。これが私に起こったことです。私のバージョンのgitでは、これを使用してこれを発見できます

git 差分 index.htm

ファイルモードの変更が表示されます。ただし、 -f オプションを使用しても、チェックアウトを使用してそれらを元に戻すことはできません。その使用のために

git config core.filemode false

または、追加してテキストエディターで git .config を変更します

[芯]

filemode = false

これを行った後、使用できます

git リセット HEAD index.htm

ファイルが消えるはずです。

(これはすべて、モードの変更を無視するようにするにはどうすればよいですか (chmod)?およびupdates-file-permissions-only-in-gitへの回答から得ました)

于 2012-06-13T15:42:48.223 に答える
6

OSX または Windows を使用していますか? その場合、問題はおそらく、大文字と小文字が異なる同じ名前の 2 つのファイルがあることです。例えば。index.htm と Index.htm

Windows、およびデフォルトでは OSX は大文字と小文字を区別しないファイル システムを使用しますが、これは大文字と小文字を区別する git と競合します。

于 2014-07-02T07:42:13.233 に答える
3

この問題が発生し、上記のすべてを試した後、何も機能しませんでした。

私にとってうまくいったのは、ファイルがあったディレクトリを削除してから、git statusそのディレクトリ内のすべてのファイルが削除済みとしてマークされていることを確認することでした。その後、私は単にやっただけgit checkout -fで、すべてが正常に戻りました.

于 2016-06-15T18:45:47.200 に答える
0

存在しないか変更されたファイルを破棄できないという同様の問題がありました。仕事で Visual Studio を使用していますが、アプリの実行中にブランチを切り替えると、これが発生することがわかりました。

git checkout破棄しようとしても役に立ちませんでした。うまくいかないか、許可がないと教えてくれるだけです。

うまくいった解決策：

  1. セーフモードに入る
  2. ファイルを破棄

再起動は面倒ですが、これは 100 のことを試すよりも速く機能しました。

于 2015-10-14T19:26:23.547 に答える
0

私にとって、この問題は、Netlify CMS 経由でアップロードされ、Netlify Large Media ハンドラーによって異なる方法で提供された Git-LFS イメージのダウンロードの組み合わせで発生しました。

私の解決策は、これらの行をコメントアウト/削除して、~/.gitconfig以下のようにしてからgit status再度チェックすることでした。

# [filter "lfs"]
#   clean = git-lfs clean %f
#   smudge = git-lfs smudge %f
#   required = true

または、レポルートの a を介してよりローカルなフィルターを追加し、.gitconfigそこで lfs のフィルタールールを上書きすることもできます。

これが仲間を助けることを願っています。

于 2020-06-15T18:55:25.000 に答える
0

これは古い質問ですが、それでも私には関係がありました。オフィスで尋ねるまで答えが見つかりませんでしたが、問題がサブモジュールにあることがわかりました。それらが更新され、独自のリポジトリにそれらの変更が反映されていない場合、違いがあると表示され、ヘッドをリセットしても役に立ちません。この場合は、次を実行します。

git status update

それは物事を修正するのに役立つはずです（この特定のケースでは）

于 2017-10-31T20:20:18.030 に答える