статус 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. убедитесь, что файлы по-прежнему не помечены как измененные.

для будущих людей, имеющих эту проблему: изменение filemode также может иметь те же симптомы. 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 repo с проектом glfw

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

решила:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

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

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 по как этот: * text=auto

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

затем 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. Но когда я попытался ... --2--> и 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 что позволило мне увидеть то, что формат файла на statusline ВИМ)

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

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

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

git commit-m "Random commit"

git reset --hard HEAD~1

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

git reset --hard
git pull origin
git merge

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

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

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

$ 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

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