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

Я хотів би видалити всі зміни до своєї робочої копії.
Запуск 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, автоматично перетворюючи crlf в lf. Зазвичай це викликано змішаними закінченнями рядків в одному файлі. Файл нормалізується в індексі, але коли git потім денормалізує його знову, щоб відрізняти його від файла в робочому дереві, результат є іншим.

Але якщо ви хочете виправити це, вам слід відключити core.autocrlf , змінити всі закінчення рядка на lf, а потім знову включити його. Або ви можете відключити його, виконавши:

git config --global core.autocrlf false

Замість core.autocrlf ви також можете використовувати .gitattributeфайли. Таким чином, ви можете переконатися, що кожен, хто використовує РЕПО, використовує однакові правила нормалізації, не дозволяючи змішаним закінченням рядків потрапляти у сховище.

Також розглянути можливість встановлення core.safecrlf попереджати, якщо ви хочете, щоб git попередив вас, коли буде здійснена незворотна нормалізація.

Про це говорять керівники git :

Перетворення CRLF має незначний шанс зіпсувати дані. autocrlf = true перетворить CRLF в LF під час фіксації, а LF в CRLF під час оформлення замовлення. Файл, який містить суміш LF та CRLF перед фіксацією, не може бути відтворений git. Для текстових файлів це правильно зробити: він виправляє закінчення рядків таким чином, що у нас є лише закінчення рядків LF у сховищі. Але для бінарних файлів, які випадково віднесені до тексту, конверсія може пошкодити дані.

Файлові системи, нечутливі до регістру

У файлових системах, що не враховують регістр, коли однакове ім’я файлу з різним корпусом знаходиться у сховищі, git намагається перевірити обидва, але у файловій системі лише одна. Коли git намагається порівняти другий, він порівняв би його з неправильним файлом.

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

У мене виникала ця проблема в 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 repo з проектом 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

Зараз у мене майже всі файли в моєму сховищі змінені.

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

Вид тривожних. Зараз я буду уникати приховування в майбутньому ..

Єдине рішення - клонувати нове сховище та починати заново. (Зробив востаннє)

Спробуйте зробити

git checkout -f

Це має очистити всі зміни в діючій місцевій репо-службі

Мені вдалося виправити це лише тимчасовим видаленням .gitattributes файлу мого репо (який визначено * text=autoта *.c text).

Я вибіг git statusпісля видалення і модифікацій не було. Вони не повернулися навіть після того, як .gitattributes було повернуто на місце.

Послідовне закінчення рядків - це добре. Наприклад, це не спровокує зайвих злиттів, хоч і тривіальних. Я бачив, як Visual Studio створює файли зі змішаними закінченнями рядків.

Також деякі програми, такі як bash (на Linux), вимагають, щоб .sh файли закінчувалися.

Щоб переконатися, що це трапиться, ви можете використовувати 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ньому підписується як видалений, і в незавершених файлах я міг бачити app.js. Але коли я знову спробував rm -rf app.jsі сформулював форму, git statusвін все ще показує мені файл "без нагляду".

Після кількох спроб з колегою ми з'ясували, що це було викликано Грунтом!

Як Gruntувімкнено, і оскільки app.js був створений з кількох інших файлів js, ми з'ясували, що після кожної операції з js-файлами (також цим app.js) грунт знову відтворив app.js.

Ця проблема також може виникнути, коли дописувач до репо працює на машині Linux або змінюються вікна з правами Cygwin та файлів. Гіт знає лише 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

Тут є маса рішень, і я, можливо, мав би спробувати деякі з них, перш ніж придумати своє. У будь-якому випадку тут є ще один ...

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

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

Я здійснив усі зміни, а потім зробив і скасував комісію. Це працювало для мене

git add.

git commit -m "Випадкова комісія"

git reset - тверда голова ~ 1

Як правило, в GIT для очищення всіх модифікацій та нових файлів наступні 2 команди повинні працювати дуже добре (будьте ДОСТУПНІ , це видалить усі ваші нові файли + папки, які ви створили, і відновить усі ваші змінені файли до стану поточного вчинити ):

$ git clean --force -d
$ git checkout -- .

Можливо, кращим варіантом іноді є просто "git stash push" з додатковим повідомленням, наприклад:

$ git stash push -m "not sure if i will need this later"

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

Як зауваження, якщо ви вже створили кілька доданих файлів і хочете їх позбутися, це слід зробити:

$ git reset --hard

Якщо все вищезазначене не працює для вас , читайте нижче, що працювало для мене деякий час тому:

Раніше я стикався з цією проблемою. Зараз я розробляю на машині Windows 10, яку надає мій роботодавець. Сьогодні саме ця поведінка git була викликана мною, створюючи нову гілку з моєї гілки "розвивати". З якоїсь причини, після того, як я переключився на «розробку» гілки, деякі, здавалося б, випадкові файли зберігалися і відображалися як «модифіковані» у «статусі git».

Крім того, на той момент я не міг оформити іншу гілку, тому я застряг на своїй гілці «розвинути».

Ось що я зробив:

$ git log

Я помітив, що нова галузь, яку я створив із "розвинутий" раніше сьогодні, показала в першому повідомленні "здійснити", на яке посилалося в кінці "HEAD -> розвиватися, походження / розвивати, походження / 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

Це, можливо, спрацювало також, я обов'язково спробую це наступного разу, коли зіткнуся з цією проблемою.

Якщо ви клонуєте сховище і миттєво бачите зміни, що очікують, то сховище перебуває у непослідовному стані. Будь ласка , НЕ закомментировать * text=autoз .gitattributesфайлу. Це було розміщено спеціально тому, що власник сховища хоче, щоб усі файли зберігалися послідовно із закінченнями рядка 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

Для мене проблема полягала в тому, що Visual Studio був відкритий при виконанні команди

git checkout <file>

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

Ми зіткнулися з подібною ситуацією в нашій компанії. Жоден із запропонованих методів нам не допоміг. В результаті досліджень було виявлено проблему. Річ у тім, що в Git було два файли, назви яких відрізнялися лише в регістрі символів. Unix-системи розглядали їх як два різні файли, але Windows збожеволіла. Щоб вирішити проблему, ми видалили один із файлів на сервері. Після цього в локальних сховищах Windows допомогли наступні кілька команд (у різних послідовностях):

git reset --hard
git pull origin
git merge

Я вирішив це, відредагувавши .git / config, додавши:

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

Потім я перейшов до .git / refs / heads / name_branch і вставлю ідентифікатор останнього комітуenter code here

Я вирішив це таким чином:

1. Скопіюйте вміст потрібного коду
2. Видаліть файл, який викликає проблему (той, який ви не можете відновити) з диска. тепер ви повинні знайти обидві версії одного файлу, позначені як видалені.
3. Зробіть видалення файлів.
4. Створіть файл знову з тим самим іменем та вставте правильний код, який ви скопіювали на кроці 1
5. здійснити створення нового файлу.

Ось що для мене спрацювало.

Одне запропоноване рішення тут не спрацювало, я з’ясував, що файл насправді є посиланням на деякі спеціальні символи:

% ls -l StoreLogo.png
lrwxrwxrwx 1 janus janus 8 Feb 21 10:37 StoreLogo.png -> ''$'\211''PNG'$'\r\n\032\n'

% git status    
Changes not staged for commit:
    modified:   StoreLogo.png

% git rm --cached -r StoreLogo.png
rm 'src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png'

% git reset StoreLogo.png         
Unstaged changes after reset:
M   src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png

% git status                      
Changes not staged for commit:
    modified:   StoreLogo.png