Я хотел бы удалить все изменения в моей рабочей копии.
Бег 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")
git
revert
git-status
working-copy
rbellamy
источник
источник
git reset --hard
не работает. Примечание: следуетgit checkout -- `git ls-files -m`
отменить файлы (--
)checkout -- <file>
его, должно работать. Обнаружение изменений в некоторых ситуациях немного придирчиво (среди прочих, если присутствует несоответствие CRLF)git update-index --assume-unchaged
принудительно изменяет состояние файлов (даже для измененных!)Ответы:
Есть много проблем, которые могут вызвать это поведение:
Нормализация конца строки
У меня тоже были такие проблемы. Все сводится к тому, что git автоматически конвертирует crlf в lf. Обычно это вызвано смешанным окончанием строки в одном файле. Файл нормализуется в индексе, но когда git затем снова денормализует его, чтобы сравнить его с файлом в рабочем дереве, результат будет другим.
Но если вы хотите это исправить, вы должны отключить core.autocrlf , изменить все окончания строк на lf, а затем включить его снова. Или вы можете отключить его, выполнив:
Вместо core.autocrlf вы также можете рассмотреть возможность использования
.gitattribute
файлов. Таким образом, вы можете быть уверены, что все, кто использует репо, используют одни и те же правила нормализации, предотвращая попадание концов смешанных строк в репозиторий.Также рассмотрите возможность установки core.safecrlf для предупреждения, если вы хотите, чтобы git предупреждал вас, когда будет выполнена необратимая нормализация.
Git manpages говорят это:
Нечувствительные к регистру файловые системы
В нечувствительных к регистру файловых системах, когда в хранилище находится одно и то же имя файла с другим регистром, git пытается извлечь оба, но в файловой системе появляется только одно. Когда git пытается сравнить второй, он сравнивает его с неверным файлом.
Решением может быть либо переключение на файловую систему без учета регистра, но в большинстве случаев это невозможно, либо переименование и фиксация одного из файлов в другой файловой системе.
источник
git ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d
. Чтобы перечислить имена таких файлов в верхнем и нижнем регистре, запуститеgit ls-tree -r --name-only HEAD | fgrep -i -f <(git ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d) | sort -i
У меня была эта проблема в Windows, но я не был готов рассмотреть последствия использования.
config --global core.autocrlf false
Я также не был готов отказаться от других частных веток и вкусностей в своем тайнике и начать с нового клона. Мне просто нужно что-то сделать. Сейчас.Это сработало для меня, при том, что вы позволили git полностью переписать ваш рабочий каталог:
(Обратите внимание, что запуск не
git reset --hard
был достаточно хорош, и не было простойrm
в файлах до того,reset
как предлагается в комментариях к исходному вопросу)источник
core.autocrlf
не имел никакого эффекта.core.autocrlf false
. Этот ответ сработал, когда больше ничего не будет.Другое решение, которое может работать для людей, так как ни один из вариантов текста не работал для меня:
.gitattributes
с одной строки:* binary
. Это говорит git обрабатывать каждый файл как двоичный файл, с которым он ничего не может сделать.git checkout -- <files>
восстановить их до версии хранилища.git checkout -- .gitattributes
восстановить.gitattributes
файл в исходное состояниеисточник
.gitattributes
к оригиналу приведет к повторному появлению той же проблемы, но, увы, моя проблема теперь решена. Ни одно из других предложений не сработало в моем случае.git status
, он обнаруживает, что это разные файлы. Когда вы спрашиваетеgit checkout
, он обнаруживает, что они имеют одинаковое содержание. Это решение временно инструктирует git игнорировать любую возможную хитрость конца строки и гарантирует, что ваша локальная копия является побайтовой, идентичной копии вHEAD
. После того, как это будет решено, разрешить возобновить ловкость можно, потому что это не добавит новых ошибок.Для будущих людей, имеющих эту проблему: Изменения в файловом режиме также могут иметь те же симптомы.
git config core.filemode false
это исправлю.источник
git checkout .
git diff
и он покажет файлы с изменениями режима, подобными этимold mode 100755 / new mode 100644
.Это сводило меня с ума, тем более, что я не мог исправить это без каких-либо решений, найденных в Интернете. Вот как я это решил. Не могу взять кредиты здесь, так как это работа коллеги :)
Источник проблемы: моя первоначальная установка git была без автоматического преобразования строки в Windows. Это привело к тому, что мой первоначальный коммит в GLFW не имел правильного окончания строки.
Установка: Xubuntu 12.04 Git-репо с проектом glfw
Проблема: не удалось сбросить файлы glfw. Они всегда отображаются как измененные, независимо от того, что я пытался.
Решено:
источник
У меня был файл .bat с той же проблемой (не удалось избавиться от него в неотслеживаемых файлах). git checkout - не сработало, ни одно из предложений на этой странице. Единственное, что сработало для меня, это сделать:
А затем удалить тайник:
источник
--keep-index
это важно.Получил ту же проблему дважды! Оба раза, когда спрятали некоторые изменения, я сделал, а затем попытался вернуть их обратно. Невозможно внести изменения, так как у меня есть много файлов, которые были изменены, но это не так! Они точно такие же.
Теперь я думаю, что я попробовал все вышеупомянутые решения без успеха. После попытки
Теперь я получил почти все файлы в моем хранилище изменены.
При разметке файла он говорит, что я удалил все строки, а затем добавил их снова.
Вид беспокойства. Теперь я не буду прятаться в будущем.
Единственное решение - клонировать новый репозиторий и начать заново. (Сделал это в прошлый раз)
источник
Попробуйте сделать
Это должно очистить все изменения в текущем рабочем локальном репо
источник
git checkout -f <another recent branch>
затем вернуться к моей ветви сgit checkout -f <branch I'm working on>
Я смог исправить это только путем временного удаления файла .gitattributes моего репо (который определил
* text=auto
и*.c text
).Я побежал
git status
после удаления, и изменения исчезли. Они не вернулись даже после того, как .gitattributes был возвращен на место.источник
Наличие последовательных окончаний строк - это хорошо. Например, это не вызовет ненужных слияний, хотя и тривиальных. Я видел, как Visual Studio создавал файлы со смешанными окончаниями строк.
Кроме того, некоторые программы, такие как bash (в linux), требуют, чтобы файлы .sh заканчивались LF.
Чтобы убедиться в этом, вы можете использовать gitattributes. Он работает на уровне хранилища независимо от значения autcrlf.
Например, вы можете иметь .gitattributes как это: * text = auto
Вы также можете быть более конкретны для каждого типа / расширения файла, если это имело значение в вашем случае.
Затем autocrlf может конвертировать окончания строк для программ Windows локально.
На смешанном проекте C # / C ++ / Java / Ruby / R, Windows / Linux это работает хорошо. Пока никаких проблем.
источник
У меня были такие же симптомы, но были вызваны другой вещью.
Я не смог:
даже на
git rm --cached app.js
нем отмечены как удаленные, так и в неотслеживаемых файлах я видел app.js. Но когда я попытался сноваrm -rf app.js
выполнить команду peform,git status
он все еще показывает мне файл «без отслеживания».После пары попыток с коллегой мы узнали, что это было вызвано Grunt!
Так как
Grunt
он был включен, и поскольку app.js был сгенерирован из пары других js-файлов, мы обнаружили, что после каждой операции с js-файлами (также это app.js) grunt снова воссоздает app.js.источник
Эта проблема также может возникать, когда участник репо работает на компьютере с Linux или когда меняются окна с Cygwin и разрешениями для файлов. Git знает только о 755 и 644.
Пример этой проблемы и как проверить это:
Чтобы избежать этого, вы должны убедиться, что вы правильно настроили git, используя
источник
Здесь есть много решений, и я, возможно, должен был попробовать некоторые из них, прежде чем придумать свое собственное. В любом случае вот еще один ...
Наша проблема заключалась в том, что у нас не было принудительного применения конечных линий, а в хранилище было сочетание 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, как и
:set ff=unix
в VIM. (Обратите внимание, что я установил https://github.com/itchyny/lightline.vim, что позволило мне увидеть формат файла в строке состояния VIM)источник
Проблема, с которой я столкнулся, заключается в том, что windows не заботится о заглавных буквах имен файлов, а git. Так что git хранит версию файла в нижнем и верхнем регистре, но может извлечь только одну.
источник
Я зафиксировал все изменения, а затем сделал и отменил коммит. Это сработало для меня
мерзавец добавить.
git commit -m "Случайный коммит"
git reset --hard HEAD ~ 1
источник
Обычно в GIT для очистки всех ваших модификаций и новых файлов следующие 2 команды должны работать очень хорошо (будьте осторожны , это удалит все ваши новые файлы + папки, которые вы, возможно, создали, и восстановит все ваши измененные файлы до состояния вашего текущего совершить ):
Может быть, лучше иногда просто выполнить «git stash push» с дополнительным сообщением, например так:
Это также очистит все ваши новые и измененные файлы, но у вас все они будут спрятаны на случай, если вы захотите восстановить их. Stash в GIT переносится из ветви в ветку, поэтому вы можете восстановить их в другой ветке, если хотите.
В качестве примечания: если вы уже подготовили некоторые недавно добавленные файлы и хотите избавиться от них, это поможет:
Если все вышеперечисленное не работает для вас , прочитайте ниже, что работало для меня некоторое время назад:
Я столкнулся с этой проблемой несколько раз раньше. В настоящее время я работаю на компьютере под управлением Windows 10, предоставленном моим работодателем. Сегодня это специфическое поведение git было вызвано тем, что я создал новую ветку из моей ветки "разработка". По какой-то причине после того, как я снова переключился на ветку «разработка», некоторые, казалось бы, случайные файлы сохранились и показывались как «измененные» в «состоянии git».
Кроме того, в тот момент я не мог оформить заказ на другую ветку, поэтому застрял в своей ветке "разработка".
Вот что я сделал:
Я заметил, что новая ветвь, созданная мной из "Develop" ранее сегодня, отображалась в первом сообщении "commit", на которое ссылались в конце "HEAD -> Develop, origin / development, origin / HEAD, The-branch-i-создал Раньше сегодня ".
Поскольку мне это не нужно, я удалил это:
Измененные файлы все еще показывались, поэтому я сделал:
Это решило мою проблему:
Конечно
$ git stash list
, покажет спрятанные изменения, и, так как у меня было немного, и я не нуждался в своих тайниках, я сделал,$ git stash clear
чтобы УДАЛИТЬ ВСЕ ХРАНИЛИЩИ.ПРИМЕЧАНИЕ : я не пытался делать то, что кто-то предлагал здесь до меня:
Возможно, это сработало, я обязательно попробую в следующий раз, когда столкнусь с этой проблемой.
источник
Если вы клонируете хранилище и сразу видите ожидающие изменения, тогда хранилище находится в несогласованном состоянии. Пожалуйста , не закомментировать
* text=auto
из.gitattributes
файла. Это было сделано специально потому, что владелец хранилища хочет, чтобы все файлы хранились в соответствии с окончаниями строк LF.Как заявляет HankCa, следуя инструкциям на https://help.github.com/articles/dealing-with-line-endings/, вы сможете решить проблему. Простая кнопка:
Затем объедините (или вытяните запрос) ветку с владельцем репо.
источник
Больше ничего на этой странице не сработало. Это, наконец, сработало для меня. Не отображаются неотслеживаемые или зафиксированные файлы.
источник
Для меня проблема заключалась в том, что Visual Studio был открыт при выполнении команды
git checkout <file>
После закрытия Visual Studio команда сработала, и я наконец смог применить свою работу из стека. Поэтому проверьте все приложения, которые могут вносить изменения в ваш код, например SourceTree, SmartGit, NotePad, NotePad ++ и другие редакторы.
источник
Мы столкнулись с похожей ситуацией в нашей компании. Ни один из предложенных способов нам не помог. В результате исследования была выявлена проблема. Дело в том, что в Git было два файла, названия которых отличались только регистром символов. Unix-системы рассматривали их как два разных файла, но Windows сходила с ума. Чтобы решить проблему, мы удалили один из файлов на сервере. После этого в локальных репозиториях на Windows помогли следующие несколько команд (в разных последовательностях):
источник
Я решил это, отредактировав .git / config, добавив:
Затем я пошел в .git / refs /heads / name_branch и поместил идентификатор последнего коммита
enter code here
источник
Я решил это так:
Вот что сработало для меня.
источник
Одно из предложенных здесь решений не сработало, я обнаружил, что файл на самом деле является ссылкой на некоторые специальные символы:
источник