git status показывает изменения, git checkout - <file>не удаляет их

Question

Я хочу удалить все изменения в моей рабочей копии.
Запуск 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")

Answer 1

Хорошо иметь последовательные окончания строк. Например, это не вызовет ненужных слияний, хотя и тривиальных. Я видел, как Visual Studio создавал файлы со смешанными окончаниями строк.

Кроме того, некоторые программы, такие как bash (в linux), требуют, чтобы файлы .sh были завершены LF.

Чтобы убедиться в этом, вы можете использовать gitattributes. Он работает на уровне хранилища независимо от значения autcrlf.

Например, вы можете иметь .gitattributes как это: * text = auto

Вы также можете указать более конкретный тип / расширение файла, если это имеет значение в вашем случае.

Затем autocrlf может локально преобразовывать окончания строк для программ Windows.

На смешанном проекте C # / C ++ / Java / Ruby / R, Windows / Linux это работает хорошо. Пока никаких проблем.

Answer 2

Здесь есть много решений, и мне, возможно, следовало бы попробовать некоторые из них, прежде чем придумать свое собственное. В любом случае, вот еще один ...

Наша проблема заключалась в том, что у нас не было принудительного применения конечных линий, а в хранилище было сочетание DOS / Unix. Хуже всего было то, что это было на самом деле репо с открытым исходным кодом в этой позиции, и мы его раздвоили. Те, кто был основным владельцем репозитория ОС, приняли решение изменить все конечные строки на 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, поэтому пришлось :set ff=unix в VIM. (Обратите внимание, что я установил https://github.com/itchyny/lightline.vim, что позволило мне увидеть формат файла в строке состояния VIM)

6. совершено. Все отсортировано!

Answer 3

Я зафиксировал все изменения, а затем сделал и отменил коммит. Это сработало для меня

git add.

git commit -m "Случайное принятие"

git reset --hard HEAD ~ 1

Answer 4

Для меня проблема заключалась в том, что Visual Studio был открыт при выполнении команды

git checkout <file>

После закрытия Visual Studio команда сработала, и я наконец смог применить свою работу из стека. Поэтому проверьте все приложения, которые могут вносить изменения в ваш код, например SourceTree, SmartGit, NotePad, NotePad ++ и другие редакторы.

Answer 5

Эта проблема также может возникать, когда участник репо работает на компьютере с 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

Answer 6

Проблема, с которой я столкнулся, заключается в том, что windows не заботится о заглавных буквах файлов, а git. Так что git хранит версию файла в нижнем и верхнем регистре, но может извлечь только одну.

Answer 7

Если вы клонируете хранилище и сразу видите ожидающие изменения, то хранилище находится в несогласованном состоянии. Пожалуйста, НЕ комментируйте * 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

Затем объедините (или запрос на извлечение) ветку с владельцем репо.

Answer 8

Я решил это так:

1. Скопируйте содержимое нужного вам кода
2. Удалите файл, который вызывает проблему (тот, который вы не можете восстановить) с вашего диска. Теперь вы должны найти обе версии одного и того же файла, помеченные как удаленные.
3. Зафиксировать удаление файлов.
4. Снова создайте файл с тем же именем и вставьте правильный код, который вы скопировали на шаге 1
5. зафиксировать создание нового файла.

---

Вот что у меня сработало.

Answer 9

Я решил это, отредактировав .git / config, добавив:

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

Тогда я пошел в .git / refs /heads / name_branch и поместите идентификатор последнего коммита enter code here

Answer 10

Я столкнулся с этой проблемой несколько раз раньше. В настоящее время я работаю на Windows 10, предоставленной моим работодателем. Сегодня это специфическое поведение git было вызвано тем, что я создал новую ветку из моей ветки "разработка". По какой-то причине после того, как я снова переключился на ветку «разработка», некоторые, казалось бы, случайные файлы сохранились и показывались как «измененные» в «состоянии git».

Кроме того, в этот момент я не смог оформить другую ветку, поэтому застрял в своей ветке "разработка".

Вот что я сделал:

$ git log

Я заметил, что новая ветвь, созданная мной из "Develop" ранее сегодня, отображалась в первом сообщении "commit", на которое ссылается в конце "HEAD -> Develop, origin / development, origin / HEAD, ветвп-я-сотворены ранее, сегодня ».

Так как он мне действительно не нужен, я удалил его:

$ 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, ЧТОБЫ УДАЛИТЬ ВСЕ ШТЕЙКИ.

ПРИМЕЧАНИЕ : Я не пытался делать то, что кто-то предлагал здесь до меня:

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

Возможно, это сработало, я обязательно попробую в следующий раз, когда столкнусь с этой проблемой.