Git статус показывает изменения, git checkout - <файл> не удаляет их

Ответ 1

Существует несколько проблем, которые могут вызвать такое поведение:

Нормализация окончания строки

У меня тоже были такие проблемы. Он сводится к git, автоматически преобразующему crlf в lf. Обычно это вызвано концами смешанных строк в одном файле. Файл нормализуется в индексе, но когда 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 пытается проверить оба, но только один заканчивается в файловой системе. Когда git пытается сравнить второй, он сравнивает его с неправильным файлом.

Решение будет либо переключать на нечувствительную к регистру файловую систему, но это в большинстве случаев невозможно или переименовать и передать один из файлов в другой файловой системе.

Ответ 2

У меня возникла эта проблема в Windows, но я не был готов изучить последствия использования config --global core.autocrlf false. Я также не был готов отказаться от других частных ветвей и лакомства в своем кошельке и начать с нового клона. Мне просто нужно что-то сделать. Теперь.

Это сработало для меня, по идее, что вы позволили git полностью переписать рабочий каталог:

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

(Обратите внимание, что запуск только git reset --hard был недостаточно хорошим и не был простым rm в файлах перед reset, как это предлагается в комментариях к исходному вопросу)

Ответ 3

Другое решение, которое может работать для людей, поскольку ни один из вариантов текста не работал у меня:

• Замените содержимое .gitattributes на одну строку: * binary. Это говорит git обрабатывать каждый файл как двоичный файл, с которым он ничего не может сделать.
• Проверить, что сообщение для поврежденных файлов не прошло; если вы не можете git checkout -- <files> восстановить их в версию репозитория
• git checkout -- .gitattributes, чтобы восстановить файл .gitattributes в исходное состояние
• Убедитесь, что файлы по-прежнему не отмечены как измененные.

Ответ 4

Для будущих людей, имеющих эту проблему: наличие изменений в файловом режиме также может иметь те же симптомы. git config core.filemode false зафиксирует его.

Ответ 5

Это сводило меня с ума, особенно, что я не мог исправить это без каких-либо решений, найденных в Интернете. Вот как я это решил. Не могу взять кредиты здесь, так как это работа коллеги:)

Источник проблемы: Моя первоначальная установка git была без автоматического преобразования строк в Windows. Это привело к тому, что моя первоначальная фиксация GLFW была без правильной строки.

Примечание. Это только локальное решение. Следующий парень, клонирующий репо все равно будет зависеть от этой проблемы. Постоянным решением может быть найдено здесь: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository.

Настройка: Xubuntu 12.04 Git репо с проектом glfw

Проблема: не удается выполнить reset glfw файлы. Они всегда отображаются как измененные, независимо от того, что я пробовал.

Решено:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Ответ 6

У меня был .bat файл с той же проблемой (не мог избавиться от него в незатрещенных файлах). git checkout - не работает, ни одно из предложений на этой странице. Единственное, что сработало для меня, это сделать:

git stash save --keep-index

И затем, чтобы удалить тайник:

git stash drop

Ответ 7

Получил ту же проблему дважды! Оба раза, когда я делал некоторые изменения, я попытался их отбросить. Could'nt поп изменения, так как у меня есть много файлов, которые были изменены, но они НЕ! Они ТОЧНО то же самое.

Теперь я думаю, что я пробовал все вышеупомянутые решения без успеха. Попробовав

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

Теперь я получил почти все файлы в моем репозитории.

Когда вы меняете файл, он говорит, что я удалил все строки и снова добавил их.

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

Единственное решение - клонировать новый репозиторий и начинать заново. (Сделано в последний раз)

Ответ 8

Я смог исправить это, временно удалив файл repo.gitattributes(который определил * text=auto и *.c text).

Я удалил git status после удаления и изменения были удалены. Они не вернулись даже после того, как .gitattributes был возвращен на место.

Ответ 9

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

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

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

Например, у вас могут быть такие атрибуты .gitattributes:   * текст = авто

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

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

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

Ответ 10

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

Я не смог:

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 снова, он все еще показывает мне файл в "untracked".

После пары попыток с коллегой мы выяснили, что это было вызвано Grunt!

По мере включения Grunt и из-за того, что app.js был сгенерирован из нескольких других js файлов, мы выяснили, что после каждой операции с js файлами (также это app.js) grunt снова воссоздает app.js.

Ответ 11

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

Наша проблема заключалась в том, что у нас не было никаких ограничений для конечных линий, и в хранилище было соединение DOS/Unix. Хуже все еще было то, что на самом деле это было репо с открытым исходным кодом, и мы были раздвоены. Решение было принято теми, кто имеет основную собственность в репозитории ОС, чтобы изменить все конечные линии на Unix, и была сделана фиксация, включающая .gitattributes для обеспечения окончаний строки.

К сожалению, это, похоже, вызывало проблемы, подобные описанным здесь, где после слияния кода с DOS-2-Unix файлы навсегда были отмечены как измененные и не могли быть возвращены.

Во время моих исследований для этого я столкнулся - https://help.github.com/articles/dealing-with-line-endings/ - Если я снова столкнусь с этой проблемой, я сначала начну с пробуя это.

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

• Я сначала сделал слияние, прежде чем понял, что у меня возникла эта проблема, и мне пришлось отменить это - git reset --hard HEAD (Я столкнулся с конфликтом слияния. Как я могу прервать слияние?)

• Я открыл файлы в VIM и перешел на Unix (:set ff=unix). Вместо курса можно было бы использовать инструмент типа dos2unix

• совершено

• объединил master в (мастер имеет изменения DOS-2-Unix)

  git checkout old-code-branch; git merge master

• Разрешенные конфликты и файлы снова были DOS, поэтому в VIM было :set ff=unix. (Примечание. Я установил https://github.com/itchyny/lightline.vim, что позволило мне увидеть, какой формат файла находится в статусной строке VIM)

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

Ответ 12

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

Ответ 13

Если вы клонируете репозиторий и мгновенно видите ожидающие изменения, то репозиторий находится в противоречивом состоянии. Пожалуйста, не комментируйте * text=auto из файла .gitattributes. Это было сделано там специально, потому что владелец репозитория хочет, чтобы все файлы сохранялись последовательно с окончанием строки LF.

Как указано HankCa, следуя инструкциям https://help.github.com/articles/dealing-with-line-endings/, вы можете исправить проблему. Простая кнопка:

git clone [email protected]: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

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

Ответ 14

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

Ответ 15

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

git checkout <file>

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

Ответ 16

Больше ничего на этой странице не сработало. Это наконец-то сработало для меня. Не отображаются неотслеживаемые или зафиксированные файлы.

git add -A
git reset --hard

Ответ 17

Попробуйте сделать

Git Checkout -f

Это должно очистить все изменения в текущем рабочем локальном репо

Ответ 18

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

мерзавец добавить.

git commit -m "Случайный коммит"

git reset --hard HEAD ~ 1

Ответ 19

Мы столкнулись с похожей ситуацией в нашей компании. Ни один из предложенных способов нам не помог. В результате исследования была выявлена проблема. Дело в том, что в Git было два файла, имена которых отличались только регистром символов. Unix-системы рассматривали их как два разных файла, но Windows сходила с ума. Чтобы решить проблему, мы удалили один из файлов на сервере. После этого в локальных репозиториях на Windows помогли следующие несколько команд (в разных последовательностях):

git reset --hard
git pull origin
git merge

Ответ 20

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

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

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

$ git log

Я заметил, что новая ветвь, созданная мной из "Develop" ранее сегодня, отображалась в первом сообщении "commit", на которое ссылались в конце "HEAD → Develop, origin/development, origin/HEAD, The-branch-i-создал Раньше сегодня

Поскольку мне это не нужно, я удалил это:

$ 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

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

Ответ 21

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

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

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

Ответ 22

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

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

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