После git reset --hard, git statusдает мне файлы в Changes not staged for commit:разделе.

Я также попытался git reset ., git checkout -- .и git checkout-index -f -a, но безрезультатно.

Итак, как я могу избавиться от этих неустановленных изменений?

Кажется, это касается только файлов проекта Visual Studio. Weird. Смотрите эту пасту: http://pastebin.com/eFZwPn9Z . Что особенного в этих файлах, это то, что в .gitattributes у меня есть:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

Кроме того, autocrlfустановлено в false в моем глобальном .gitconfig. Может ли это быть как-то актуально?

У меня была такая же проблема, и она была связана с .gitattributesфайлом. Однако тип файла, который вызвал проблему, не был указан в .gitattributes.

Я смог решить проблему, просто запустив

git rm .gitattributes
git add -A
git reset --hard

ПОСТАНОВИЛИ !!!

Я решил эту проблему, используя следующие шаги

1) Удалить все файлы из индекса Git.

git rm --cached -r .

2) Перепишите индекс Git, чтобы подобрать все новые окончания строки.

git reset --hard

Решение было частью шагов, описанных на сайте git https://help.github.com/articles/dealing-with-line-endings/

Git не будет сбрасывать файлы, которых нет в хранилище. Так что вы можете:

$ git add .
$ git reset --hard

Это внесет все изменения, которые заставят Git узнать об этих файлах, а затем сбросить их.

Если это не сработает, вы можете попытаться спрятать ваши изменения:

$ git stash
$ git stash drop

Если вы используете Git для Windows, это, вероятно, ваша проблема

У меня была та же проблема, и тайник, полный сброс, очистка или даже все они оставляли изменения позади. Проблема оказалась в том, что режим x file не был правильно установлен git. Это «известная проблема» с git для windows. Локальные изменения отображаются в gitk и git status как старый режим 100755, новый режим 100644, без каких-либо реальных различий в файлах.

Исправление - игнорировать режим файла:

git config core.filemode false

Больше информации здесь

Хорошо, я вроде решил проблему.

Казалось, что .gitattributesфайл, содержащий:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

заставил файлы проекта казаться неустановленными. Я не знаю, почему это так, и я очень надеюсь, что кто-то, знакомый со способами мерзавца, даст нам хорошее объяснение.

Мое исправление было удалить эти файлы, и добавить autocrlf = falseпод [core]в .git/config.

Это не то же самое, что предыдущая конфигурация, так как для этого требуется каждый разработчик autocrlf = false. Я хотел бы найти лучшее решение.

РЕДАКТИРОВАТЬ:

Я прокомментировал компрометирующие строки, раскомментировал их, и это сработало. Что ... Я даже не ...!

Возможная причина № 1 - Нормализация конца строки

Одна из ситуаций, в которой это может произойти, - когда рассматриваемый файл был зарегистрирован в хранилище без правильной конфигурации для концов строк (1), в результате чего в хранилище был файл с неправильными окончаниями строк или смешанными окончаниями строк. Для подтверждения убедитесь, что git diffотображаются только изменения в окончаниях строк (по умолчанию они могут быть не видны, попробуйте git diff | cat -vувидеть возврат каретки как буквенные ^Mсимволы).

Впоследствии кто-то, вероятно, добавил .gitattributesили изменил core.autocrlfнастройку, чтобы нормализовать окончания строк (2). На основе .gitattributesили глобальной конфигурации Git применил локальные изменения к вашей рабочей копии, которые применяют запрошенную нормализацию конца строки. К сожалению, почему-то git reset --hardне отменяются эти изменения нормализации линии.

Решение

Обходные пути, в которых обнуляются локальные окончания строк, не решат проблему. Каждый раз, когда git «видит» файл, он пытается применить нормализацию, что приводит к той же проблеме.

Наилучший вариант - позволить git применить требуемую нормализацию путем нормализации всех концов строк в репо, чтобы они соответствовали .gitattributes, и фиксации этих изменений - см. Попытка исправить окончания строк с помощью git filter-branch, но безуспешно .

Если вы действительно хотите попытаться отменить изменения в файле вручную, то, кажется, самое простое решение - стереть измененные файлы, а затем указать git восстановить их, хотя я отмечаю, что это решение не работает согласованно на 100%. время ( ВНИМАНИЕ: НЕ запускайте это, если ваши измененные файлы имеют изменения, отличные от окончаний строки !!):

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

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

Возможная причина № 2 - нечувствительность к регистру

Вторая возможная причина - нечувствительность к регистру в Windows или Mac OS / X. Например, допустим, что в хранилище существует следующий путь:

/foo/bar

Теперь кто-то в Linux фиксирует файлы в /foo/Bar(возможно, из-за инструмента сборки или чего-то, что создало этот каталог) и отправляет. В Linux это фактически две отдельные директории:

/foo/bar/fileA
/foo/Bar/fileA

Проверка этого репо в Windows или Mac может привести к изменению, fileAкоторое не может быть сброшено, потому что при каждом сбросе git в Windows проверяется /foo/bar/fileA, а затем, поскольку Windows не учитывает регистр, перезаписывает содержимое fileAwith /foo/Bar/fileA, в результате чего они «модифицируются».

Другим случаем может быть отдельный файл (ы), который существует в репо, который при извлечении в нечувствительной к регистру файловой системе будет перекрываться. Например:

/foo/bar/fileA
/foo/bar/filea

Могут быть и другие подобные ситуации, которые могут вызвать такие проблемы.

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

Решение

Решение состоит в том, чтобы привести в соответствие регистр файлов в индексе git и регистр в файловой системе Windows. Это можно сделать либо в Linux, который покажет истинное положение вещей, либо в Windows с очень полезной утилитой с открытым исходным кодом Git-Unite . Git-Unite применяет необходимые изменения регистра к индексу git, который затем может быть зафиксирован в репо.

(1) Это было, скорее всего, кем-то, кто использовал Windows, без какого-либо .gitattributesопределения для рассматриваемого файла, и использовал глобальную настройку по умолчанию, для core.autocrlfкоторой false(см. (2)).

(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

Если другие ответы не работают, попробуйте добавить файлы, а затем сбросить

$ git add -A
$ git reset --hard

В моем случае это помогло, когда была куча пустых файлов, которые отслеживал git.

Другой причиной этого могут быть нечувствительные к регистру файловые системы . Если у вас есть несколько папок в вашем репо на одном уровне, имена которых отличаются только регистром, вы будете поражены этим. Просмотрите исходный репозиторий, используя его веб-интерфейс (например, GitHub или VSTS), чтобы убедиться.

Для получения дополнительной информации: https://stackoverflow.com/a/2016426/67824

Вы можете stashудалить свои изменения, а затем выбросить тайник:

git stash
git stash drop

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

Запустите чистую команду:

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd

Проверьте свой .gitattributes.

В моем случае у меня *.js text eol=lfв нем и git вариант core.autocrlfбыл true.

Это приводит меня к ситуации, когда git автоматически конвертирует окончания строк моих файлов и мешает мне это исправить и даже git reset --hard HEADничего не делает.

Я исправляю это, комментируя *.js text eol=lfв моем, .gitattributesи оставляю комментарий после него.

Похоже, это просто волшебство.

Я столкнулся с аналогичной проблемой, которая также затрагивала .gitattributes, но в моем случае это LFS GitHub. Хотя это не совсем сценарий OP, я думаю, что он дает возможность проиллюстрировать, что .gitattributesделает файл и почему он может привести к неустановленным изменениям в форме «фантомных» различий.

В моем случае, файл уже был в моем хранилище, как с начала времен. В недавнем коммите я добавил новое git-lfs trackправило, используя шаблон, который был задним числом слишком широким, и в конечном итоге соответствовал этому древнему файлу. Я знаю, что не хотел менять этот файл; Я знаю, что не менял файл, но теперь он был в моих неустановленных изменениях, и никакие проверки или повторные сбросы этого файла не собирались исправить Зачем?

Расширение GitHub LFS работает в основном за счет использования хуков, которые gitобеспечивают доступ через .gitattributesфайл. Как правило, записи .gitattributesуказывают, как должны обрабатываться соответствующие файлы. В случае OP это было связано с нормализацией концов строк; по моему, было ли позволить LFS обрабатывать хранилище файлов. В любом случае, фактически файл, который gitвидит при вычислении a git diff, не совпадает с файлом, который вы видите при проверке файла. Следовательно, если вы измените способ обработки файла с помощью .gitattributesшаблона, который соответствует ему, он будет отображаться как неустановленные изменения в отчете о состоянии, даже если в файле действительно нет изменений.

Все, что я сказал, мой «ответ» на вопрос: если .gitattributesвы хотите сделать изменение в файле, вам следует просто добавить изменения и двигаться дальше. Если нет, то внесите изменения, .gitattributesчтобы лучше представлять, что вы хотите делать.

Ссылки

1. GitHub LFS Specification - отличное описание того, как они подключаются к вызовам функций cleanи, smudgeчтобы заменить ваш файл в gitобъектах простым текстовым файлом с хэшем.

2. gitattributes Documentation - Вся подробная информация о том, что доступно для настройки gitпроцесса обработки ваших документов.

У меня такая же проблема. Я делал, git reset --hard HEADно каждый раз, когда я делал, git statusя видел некоторые файлы как измененные.

Мое решение было относительно простым. Я просто закрыл свою IDE (здесь это был Xcode) и закрыл командную строку (здесь это был терминал на моей Mac OS) и попробовал снова, и это сработало.

Тем не менее, я так и не смог найти причину проблемы.

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

git checkout master -f
git checkout <your branch>

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

Изменить: я мог бы действительно повезло в первый раз. Оказывается, я снова получил немного после переключения веток. Оказалось, что файлы, о которых git сообщает, были изменены после изменения веток. (Очевидно, потому что git не всегда правильно применял конец файла CRLF к файлам.)

Я обновился до последней версии Git для Windows и надеюсь, что проблема исчезла.

Аналогичная проблема, хотя я уверен, только на поверхности. В любом случае, это может кому-то помочь: что я сделал (FWIW, в SourceTree): спрятал незафиксированный файл, затем сделал полный сброс.

Как указывалось в других ответах, проблема в автокоррекции конца строки. Я столкнулся с этой проблемой с * .svg файлами. Я использовал файл SVG для иконок в моем проекте.

Чтобы решить эту проблему, я дал понять git, что файлы svg следует рассматривать как двоичные, а не текстовые, добавив следующую строку в .gitattributes

* .svg бинарный

В похожей ситуации. В результате многолетних мучений со многими программистами, которые смогли собрать разные кодировки концов строк ( .sp , .js, .css ... не суть) в один файл. Некоторое время назад отказался .gitattributes. Настройки для репо оставлены autorclf = trueи safecrlf = warn.

Последняя проблема возникла при синхронизации из архива с разными концами строк. После копирования из архива в git статусе многие файлы меняются с пометкой

The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in ...

Советы от Как нормализовать рабочие окончания линий деревьев в Git? помог

git add -u

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

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   path/to/package (new commits)

Переход в path/to/packageпапку a git statusдолжен дать следующий результат:

HEAD detached at 7515f05

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

git checkout master

И вы получите сообщение о том, что ваша локальная ветвь будет иметь некоторое количество коммитов за удаленной веткой git pullи ты должен быть вне леса!

По какой-то причине

git add .

не работал , но

$ git add -A

сработало!