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

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

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

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

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

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

1. заменить содержимое .gitattributes с одной строки: * binary. Это говорит git, чтобы рассматривать каждый файл как двоичный файл, с которым он ничего не может сделать.
2. проверьте, что сообщение для оскорбительных файлов исчезло; если это не так, вы можете git checkout -- <files> чтобы восстановить их в версии репозитория
3. git checkout -- .gitattributes восстановить .gitattributes файл к своему начальному государство
4. убедитесь, что файлы по-прежнему не помечены как измененные.

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

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

источник проблемы: моя первоначальная установка git была без автоматического преобразования строки в windows. Это привело к тому, что моя первоначальная фиксация на GLFW была без надлежащего окончания строки.

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

настройка: Xubuntu 12.04 Git РЕПО с проектом glfw

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

решила:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

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

git stash save --keep-index

а затем удалить тайник:

git stash drop

получил ту же проблему дважды! Оба раза, когда я прятал некоторые изменения, которые я сделал, а затем попытался их вернуть. Не мог поп изменения, так как у меня есть много файлов, которые изменены-но они не являются! Они точно такие же.

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

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

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

при дифференцировании файла он говорит, что я удалил все строки, а затем добавьте их еще раз.

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

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

я смог исправить это только путем временного удаления моего РЕПО .gitattributes файл (который определен * text=auto и *.c text).

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

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

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

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

например, вы можете иметь .gitattributes like этот: * текст=авто

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

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

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

у меня тоже такие же симптомы, но был вызван разные вещи.

Я не смог:

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

даже на git rm --cached app.js он подписывается как удаленный и в неотслеженных файлах я мог видеть приложение.js. Но когда я попробовал rm -rf app.js и peform git status снова он все еще показывает мне файл в "untracked".

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

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

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

наша проблема заключалась в том, что у нас не было принудительного применения для конечных линий, а в репозитории было сочетание 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 in (мастер имеет изменения 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. совершено. Все разобрались!

эта проблема также может возникнуть, когда участник РЕПО работает на компьютере Linux или Windows с разрешениями Cygwin и file изменяется. 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

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

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

git checkout <file>

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

Если вы клонируете репозиторий и мгновенно видите ожидающие изменения, то репозиторий находится в несогласованном состоянии. Пожалуйста, не комментируйте * text=auto С . Это было сделано специально, потому что владелец репозитория хочет, чтобы все файлы хранились последовательно с окончаниями строк 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

затем слейте (или вытяните запрос) ветку к владельцу РЕПО.

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

git add -A
git reset --hard

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

git checkout-f

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

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

git add .

git commit-m "Random commit"

git reset --hard HEAD~1

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

git reset --hard
git pull origin
git merge

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

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

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

$ git log

я заметил, что новая ветвь, которую я создал из" develop "ранее сегодня, показывалась в первом сообщении "commit", на которое ссылаются в конце " HEAD -> develop, origin/develop, 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

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