web-dev-qa-db-ja.com

git statusは変更を示し、git checkout-<file>はそれらを削除しません

作業コピーへのすべての変更を削除したいと思います。
_git statusを実行すると、変更されたファイルが表示されます。
これらの変更を削除することはありません。
例えば。：

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")
gitrevertgit-statusworking-copy
209
rbellamy

この動作を引き起こす可能性のある複数の問題があります。

行末の正規化

私もこの種の問題を抱えています。 crlfをlfに自動的に変換するgitになります。これは通常、単一ファイル内の行末が混在していることが原因です。ファイルはインデックス内で正規化されますが、gitが再び非正規化して作業ツリー内のファイルと比較すると、結果は異なります。

ただし、これを修正する場合は、core.autocrlfを無効にし、すべての行末をlfに変更してから、再度有効にする必要があります。または、次のようにして完全に無効にすることができます。

git config --global core.autocrlf false

core.autocrlfの代わりに、 .gitattribute ファイルの使用を検討することもできます。この方法により、リポジトリを使用するすべてのユーザーが同じ正規化ルールを使用し、混合行末がリポジトリに入らないようにすることができます。

また、core.safecrlfを設定して、非可逆正規化が実行されるときにgitに警告するようにしたい場合に警告することも検討してください。

Git manpages これを言ってください：

CRLF変換では、データが破損する可能性がわずかにあります。 autocrlf = trueは、コミット時にCRLFをLFに、チェックアウト時にLFをCRLFに変換します。コミット前にLFとCRLFが混在するファイルは、gitで再作成できません。テキストファイルの場合、これは正しいことです。リポジトリにLFの行末のみがあるように行末を修正します。ただし、誤ってテキストとして分類されたバイナリファイルの場合、変換によってデータが破損する可能性があります。

大文字と小文字を区別しないファイルシステム

大文字と小文字を区別しないファイルシステムでは、大文字と小文字が異なる同じファイル名がリポジトリにある場合、gitは両方をチェックアウトしようとしますが、ファイルシステムでは1つだけになります。 gitが2番目のものを比較しようとすると、間違ったファイルと比較されます。

解決策は、大文字と小文字を区別しないファイルシステムに切り替えることですが、ほとんどの場合、これは実行不可能であるか、別のファイルシステムのファイルの名前を変更してコミットします。

123
Ikke

私はWindowsでこの問題を抱えていましたが、config --global core.autocrlf falseを使用した場合の影響を調べる準備ができていませんでした。何かする必要があるだけです。今。

Gitに作業ディレクトリを完全に書き換えさせるという考えで、これはうまくいきました。

git rm --cached -r .
git reset --hard

（元の質問へのコメントで示唆されているように、rmの前のファイルでgit reset --hardを実行するだけでは十分ではなく、プレーンresetでもなかったことに注意してください）

199
Rian Sanderson

テキストオプションはどれも役に立たなかったため、人々に役立つ別のソリューション：

  1. .gitattributesの内容を単一行* binaryに置き換えます。これは、すべてのファイルを何も処理できないバイナリファイルとして扱うようにgitに指示します。
  2. 問題のあるファイルのメッセージが消えていることを確認してください。そうでない場合は、git checkout -- <files>でリポジトリバージョンに復元できます
  3. git checkout -- .gitattributesは、.gitattributesファイルを初期状態に復元します
  4. ファイルがまだ変更済みとしてマークされていないことを確認します。
93
zebediah49

この問題を抱えている将来の人々のために：ファイルモードを変更しても同じ症状が発生する可能性があります。 git config core.filemode falseで修正されます。

67
Marty Neal

これは私を夢中にさせています。特に、オンラインで見つかったソリューションがなければ解決できませんでした。ここに私がそれを解決した方法があります。これは同僚の仕事なので、ここでクレジットを取ることはできません:)

問題の原因：gitの最初のインストールでは、Windowsで自動行変換が行われませんでした。これにより、GLFWへの最初のコミットが適切な行末なしになりました。

注：これはローカルソリューションのみです。リポジトリを複製する次の人は、まだこの問題で立ち往生しています。永続的な解決策は、ここにあります： https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository 。

セットアップ：glfwプロジェクトを使用したXubuntu 12.04 Gitリポジトリ

問題：glfwファイルをリセットできません。私が試したものに関係なく、それらは常に修正済みとして表示されます。

解決済み：

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes
31
Richard Lalancette

同じ問題の.batファイルがありました（追跡されていないファイルでそれを取り除くことはできませんでした）。 git checkout-機能しませんでした。このページの提案も機能しませんでした。私のために働いた唯一のことは、することでした：

git stash save --keep-index

そして、隠し場所を削除するには：

git stash drop
11
moo moo

同じ問題を2回取得しました！どちらの場合も、いくつかの変更を隠してから、それらを元に戻そうとしました。変更されたファイルがたくさんあるので、変更をポップできませんでしたが、そうではありません！それらはまったく同じです。

私は今、成功せずに上記のすべてのソリューションを試したと思います。試した後

git rm --cached -r .
git reset --hard

リポジトリ内のほとんどすべてのファイルが変更されました。

ファイルを比較すると、すべての行を削除してから再度追加したと表示されます。

邪魔の種類。私は今後、隠れることを避けます。

唯一の解決策は、新しいリポジトリのクローンを作成して最初からやり直すことです。 （前回作成）

6
Fam Wired

これを修正するには、リポジトリの.gitattributesファイル（* text=autoおよび*.c textを定義した）を一時的に削除するしかありませんでした。

削除後にgit statusを実行しましたが、変更はなくなりました。 .gitattributesを元に戻した後でも、それらは戻りませんでした。

4
Artfunkel

やってみて

git checkout -f

これにより、現在動作しているローカルリポジトリのすべての変更がクリアされます。

3
nsg

ここには多くの解決策がありますが、自分で考え出す前にこれらのいくつかを試してみるべきでした。とにかくここにもう1つあります...

私たちの問題は、エンドラインの強制がなく、リポジトリにDOS/Unixが混在していたことです。さらに悪いのは、それが実際にこの位置でのオープンソースリポジトリであり、私たちが分岐したことです。 OSリポジトリの主な所有権を持つすべてのエンドラインをUnixに変更するという決定が下され、行末を強制する.gitattributesを含むコミットが行われました。

残念ながら、これにより、DOS-2-Unixが実行される前からコードのマージが行われると、ファイルは永久に変更済みとしてマークされ、元に戻せなくなるという問題が発生するようです。

このための私の研究中に私は出くわしました- https://help.github.com/articles/dealing-with-line-endings/ -これに直面した場合もう一度問題を解決するために、まずこれを試してみます

ここに私がやったことがあります：

  1. この問題があることに気づく前に、最初にマージを実行し、それを中止しなければなりませんでした-git reset --hard HEAD（ マージの競合が発生しました。どうすればマージを中止できますか？ ）

  2. 問題のファイルをVIMで開き、Unix（:set ff=unix）に変更しました。もちろんdos2unixのようなツールを使用できます

  3. 関与する

  4. masterをマージしました（マスターにDOS-2-Unixの変更があります）

    git checkout old-code-branch; git merge master

  5. 競合を解決し、ファイルは再びDOSになったため、VIMで:set ff=unixする必要がありました。 （注： https://github.com/itchyny/lightline.vim をインストールしたので、VIM statuslineのファイル形式を確認できました）

  6. 関与する。すべてソート済み！
2
HankCa

この問題は、リポジトリへの貢献者がLinuxマシンで動作する場合、またはCygwinとファイルのアクセス許可を持つウィンドウが変更された場合にも発生する可能性があります。 Gitは755と644のみを知っています。

この問題の例とその確認方法：

git diff styleguide/filename

diff --git a/filename b/filename
old mode 100644
new mode 100755

これを回避するには、次を使用してgitを正しくセットアップする必要があります。

git config --global core.filemode false
2
bg17aw

一貫した行末を持つことは良いことです。たとえば、些細ではありますが、不要なマージはトリガーされません。 Visual Studioが行末が混在したファイルを作成するのを見てきました。

また、bash（Linux）のような一部のプログラムでは、.shファイルをLFで終了する必要があります。

これを確実に行うには、gitattributesを使用できます。 autcrlfの価値に関係なく、リポジトリレベルで機能します。

たとえば、次のような.gitattributesを使用できます。* text = auto

場合によっては、ファイルの種類/拡張子ごとに詳細を指定することもできます。

次に、autocrlfはWindowsプログラムの行末をローカルで変換できます。

混合C＃/ C++/Java/Ruby/R、Windows/Linuxプロジェクトでは、これはうまく機能しています。今のところ問題はありません。

2
dpiskyulev

私も同じ症状がありましたが、原因は異なります。

私はできませんでした：

git checkout app.js //did nothing
git rm app.js //did nothing
rm -rf app.js //did nothing

git rm --cached app.jsでも削除済みとして署名され、追跡されていないファイルにはapp.jsが表示されます。しかし、rm -rf app.jsとpeform git statusをもう一度試しても、ファイルは「追跡されていない」状態のままです。

同僚と数回試した結果、Gruntが原因であることがわかりました。

Gruntがオンになっており、app.jsが他のいくつかのjsファイルから生成されているため、jsファイル（このapp.jsも含む）を使用した各操作の後、app.jsが再度作成されることがわかりました。

2
Nedvajz

すべての変更をコミットしてから、コミットして元に戻しました。これは私のために働いた

git add。

git commit -m "ランダムなコミット"

git reset --hard HEAD〜1

1
gcs06

私にとって問題は、コマンドを実行するときにVisual Studioが開かれたことでした

git checkout <file>

Visual Studioを閉じた後、コマンドは機能し、スタックから作業を最終的に適用できました。したがって、SourceTree、SmartGit、NotePad、NotePad ++などのエディターなど、コードを変更する可能性のあるすべてのアプリケーションを確認してください。

1
Jesper Lundin

リポジトリのクローンを作成し、保留中の変更を即座に確認した場合、リポジトリは一貫性のない状態です。 * text=autoファイルから.gitattributesをコメントアウトしないでください。これは、リポジトリの所有者がすべてのファイルをLFの行末で一貫して保存することを望んでいるため、特にそこに置かれました。

HankCaが述べているように、 https://help.github.com/articles/dealing-with-line-endings/ の指示に従うことは、問題を解決する方法です。簡単なボタン：

git clone git@Host:repo-name
git checkout -b normalize-line-endings
git add .
git commit -m "Normalize line endings"
git Push
git Push -u Origin normalize-line-endings

次に、ブランチをリポジトリの所有者にマージ（またはプルリクエスト）します。

1
w25r

私が遭遇した問題は、windowsはファイル名の大文字小文字を気にしないが、gitは気にするということです。そのため、gitはファイルの小文字と大文字のバージョンを保存しましたが、チェックアウトできるのは1つだけでした。

1
xaav

このページの他に何も機能しませんでした。これは最終的に私のために働いた。追跡されていない、またはコミットされたファイルを表示しません。

git add -A
git reset --hard
1
Philip Rego

当社でも同様の状況に直面しました。提案された方法はどれも私たちを助けませんでした。研究の結果、問題が明らかになりました。 問題は、Gitには2つのファイルがあり、その名前はシンボルの登録のみが異なることでした。Unixシステムはそれらを2つの異なるファイルと見なしていましたが、Windowsは狂っていました。問題を解決するには、サーバー上のファイルの1つを削除しました。その後、Windowsのローカルリポジトリで、次のいくつかのコマンドを（異なる順序で）支援しました。

git reset --hard
git pull Origin
git merge
0
bside

私はこの問題に何度か遭遇しました。現在、雇用主から提供されたWindows 10マシンで開発しています。今日、この特定のgit動作は、「開発」ブランチから新しいブランチを作成したことが原因です。何らかの理由で、「develop」ブランチに切り替えた後、いくつかのランダムなファイルが持続し、「git status」で「modified」として表示されていました。

また、その時点で別のブランチをチェックアウトできなかったため、「開発」ブランチで立ち往生しました。

これは私がやったことです：

$ git log

今日私が「develop」から作成した新しいブランチは、最初の「commit」メッセージに表示され、最後に「HEAD->開発、Origin/develop、Origin/HEAD、The-branch -i-created-earlier-today "。

本当に必要なかったので、削除しました。

$ git branch -d The-branch-i-created-earlier-today

変更されたファイルはまだ表示されていたので、私はしました：

$ git stash

これは私の問題を解決しました：

$ git status
On branch develop
Your branch is up to date with 'Origin/develop'.

nothing to commit, working tree clean

もちろん$ git stash listには隠された変更が表示されます。また、隠し場所はほとんどなく、必要ありませんでしたので、$ git stash clearを実行してすべての隠し場所を削除しました。

NOTE：私が前に誰かがここで提案したことをやろうとしなかった：

$ git rm --cached -r .
$ git reset --hard

これも同様に機能した可能性があります。次回この問題に遭遇したときに必ず試してみます。

0
derekg

私は.git/configを編集して追加しました：

[branch "name_branch"]
    remote = Origin
    merge = refs/heads/name_branch

次に.git/refs/heads/name_branchに行き、最後のcommitenter code hereのidを配置します

0
Victor Villacorta

私はこのように解決しました：

  1. 必要な正しいコードの内容をコピーします
  2. 問題の原因となっているファイル（元に戻せないファイル）をディスクから削除します。これで、同じファイルの両方のバージョンが削除済みとしてマークされているはずです。
  3. ファイルの削除をコミットします。
  4. 同じ名前でファイルを再度作成し、手順1でコピーした正しいコードを貼り付けます
  5. 新しいファイルの作成をコミットします。

それは私のために働いたものです。

0
Michael Yousrie