Как отменить неустановленные изменения в Git?
Как мне отменить изменения в моей рабочей копии, которых нет в индексе?
git-clean удаляет только неотслеживаемые файлы из рабочего дерева git-scm.com/docs/git-clean
Чтобы прояснить комментарий Asenar выше, git-clean -df может быть опасным. Он удалит локальные неотслеживаемые файлы (например, покрытые .gitignore). Внимательно прочтите все ниже и подумайте о git checkout. вместо
'git clean -df' Будьте осторожны! Я попробовал это и потерял ключевые папки, которые невозможно восстановить ... Ой!
нажатие git status дает подсказку, как это сделать! git checkout -- .
В git gui есть функция, которая безопасно отменяет изменения. .gitignore почитается этой программой, тогда как git-clean вообще не использует его.
@Readonly Я думаю, что вопрос должен быть таким: «Как мне отменить неустановленные изменения в рабочем дереве», потому что вы можете отключить изменения в промежуточной области с помощью git reset HEAD file1, который перезаписывает file1 из последней фиксации в истории фиксации в области промежуточной фиксации.
@Paulo: начиная с июля 2019 года, git status дает предложение: git restore. git restore - новая команда именно для этого. См. мое обновление 2019.
Думаю, надо поменять или вопрос, или название. Название не совпадает с заданным вопросом, неясно, охватывают ли ответы оба вопроса.
Ответы 36
Для всех неустановленных файлов в текущем рабочем каталоге используйте:
git checkout -- .
Для конкретного файла используйте:
git checkout -- path/to/file/to/revert
-- здесь, чтобы удалить устранение неоднозначности аргумента.
Начиная с Git 2.23, можно использовать более конкретный
git restore .
соотв.
git restore path/to/file/to/revert
который вместе с git switch заменяет перегруженный git checkout (глянь сюда) и, таким образом, устраняет неоднозначность аргумента.
Кажется, это канонический способ git. то есть именно то, что git говорит вам делать, если вы набираете git status
Не работает, если есть неотслеживаемые файлы. Git говорит error: The following untracked working tree files would be overwritten by checkout: ....
вопрос новичка, что значит "git checkout -." значит семантически?
Майкл: начните с git clean -df, чтобы сначала удалить все неотслеживаемые файлы, как это было предложено в ответе Мариуша выше.
@Ninjack git checkout -- . означает то же самое, что и git checkout ., за исключением того, что вы явно указываете тот факт, что вы не указываете имя ветки. Они оба говорят проверить версию HEAD в ветке, в которой я сейчас работаю '.' или же './'. Если вы делаете git checkout branch-name directory-or-file-name в целом, вы получаете HEAD-версию directory-or-file-name на ветке branch-name.
git checkout . короче
IMO это предложение не обрабатывает удаления, в то время как вариант тайника делает.
"git checkout path / to / file / to / revert", что я должен добавить, если я нахожусь в ветке и хочу, чтобы содержимое файла было заменено последней версией этого файла в ветке.
IMO этот вариант несовершенный, так как он не обрабатывает ситуацию, когда ваш измененный репозиторий не находится в ревизии HEAD на момент очистки изменений, и вы НЕ хотите обновлять его до HEAD, а хотите просто очистить изменения.
@alexykot «обновление до HEAD» означает очистку от изменений. HEAD - это ревизия, которая в настоящее время проверена.
да, действительно, у меня плохо. Однако git checkout HEAD на самом деле не отменяет для меня изменения, поэтому решение на основе stash по-прежнему является предпочтительным.
@alexykot: вы должны указать путь с git checkout, иначе он не уничтожит сделанные вами изменения! Уловка с . заключается в том, что извлечение с путем также включает все подкаталоги.
Я делаю это и получаю предупреждения о несоединенных файлах. Как мне отбросить эти не объединенные файлы?
Это приведет к отмене изменений только в существующих файлах. Он не отбрасывает новые файлы, добавленные с момента последней фиксации.
Интересно. По какой-то причине это не работает в подмодуле. Это просто сводило меня с ума! Я был ОБЯЗАН, что git clean -- . должен делать то, что я хочу. Чтение этого ответа и его тестирование подтвердили его Но почему-то НЕ РАБОТАЕТ В ПОДМОДУЛЯХ! Почему нет? <вздох>
Я предпочитаю решение git stash save --keep-index, потому что оно создает фиксацию. Даже если я сделаю git stash drop сразу после stash save, фиксацию все равно можно будет восстановить. Так что решение git stash save ... более безопасно на тот случай, если вы выбросили слишком много. Например. используя stackoverflow.com/questions/89332/recover-dropped-stash-in-g это
Хотя это кажется очевидным, я думаю, стоит отметить, что эту команду следует запускать из каталога верхнего уровня репозитория, поскольку она очищает только текущий рабочий каталог.
Вот сценарий, в котором "git checkout -." работал хорошо: я перенес репозиторий из Cygwin в Linux через USB-накопитель в формате FAT. После переноса данных в Linux, «git status» и «git diff» показали признаки многих изменений прав доступа к файлам. Были также некоторые другие файлы (заметки и прочее). Я использовал «git checkout -». чтобы отменить изменения прав доступа к файлу. Теперь git diff чистый, а статус git показывает только несколько добавленных файлов. «Чистый» шаг из другого ответа был бы полезен, если бы я хотел избавиться от неотслеживаемых файлов.
Всегда ли лучше использовать двойное тире git checkout -- path/to/file/to/revert?
@ MichałTrybus, чтобы очистить весь репозиторий независимо от того, где вы в нем находитесь, вы можете использовать git checkout -- :/ (я сам искал это!)
Я очень смущен, это (git checkout -.) Просто работает нет. У меня все еще есть все мои файлы изменений (неустановленные).
Странный PandaWood. Я просто использовал это решение, и оно сделало именно то, что я хотел.
Предположим, я внес изменения в файл A (state1), и файл был изменен на Master (state2). Если я сделаю git checkout A, на какое состояние он будет указывать сейчас, предыдущее состояние1 или обновленное состояние2 .. ??
На основании информации из других источников и личного эксперимента git checkout -. Учитывает перезапись файлов только в том случае, если соответствующий файл уже существует в индексе. @MichaelIles Мне кажется, что файлы, вызывающие у вас проблемы, должны были иметь зарегистрированные версии где-то еще.
Это удаляет все незафиксированные изменения. Если я хочу удалить только изменения, сделанные после git add <filename>?
@ABMagil: теперь есть новая команда: git restore, и это та, которую теперь дает git status. Смотрите мой Обновление 2019
Чтобы вернуть всю подпапку, это хорошо работает для меня git checkout -f -- path/to/revert/ , тогда как это НЕ работает git checkout -f -- path/to/revert/*, поскольку любые новые файлы git не имеют записи.
Еще один более быстрый способ:
git stash save --keep-index --include-untracked
Вам не нужно включать --include-untracked, если вы не хотите вдаваться в подробности.
После этого вы можете сбросить этот тайник с помощью команды git stash drop, если хотите.
И чтобы быть внимательным, вам также может понадобиться --include-untracked.
Я думаю, что лучше использовать git reset --hard, если вы не хотите отслеживать изменения
@KarimSamir: Вопрос конкретно касается изменений, которые относятся к не в индексе. Команда git reset также отменит изменения в индексе.
git checkout -. намного быстрее
Ни git stash, ни какой-либо другой вариант git checkout не будет отбрасывать неустановленные удаления. Согласно выходным данным git status, на самом деле правильный ответ здесь - это какой-то вкус git reset HEAD.
Это загрязняет стек тайника. git checkout -- . выполняет работу только с помощью одной команды.
@FelipeTonello Я хотел бы дать вам 100 репутации за этот комментарий. В моем тесте это выглядело именно так, как я хотел. Вместо этого я провел последний час, используя команду «git checkout - *» и работая над всеми неотслеживаемыми ошибками файлов.
@ T.J.Crowder Как вообще Git знает, как вернуть неотслеживаемый файл? Он его просто удаляет?
@NathanArthur: Верно. Git помещает неотслеживаемый файл в тайник, а затем удаляет его из рабочего дерева. При восстановлении тайника неотслеживаемый файл копируется в рабочее дерево, поэтому он снова отображается как новый неотслеживаемый файл.
@ChrisWarth - git checkout - у меня не работает. Статус Git по-прежнему показывает неотслеживаемые изменения.
Как мы можем сделать то же самое с помощью Source Tree?
git checkout - файл
В том же духе, что и этот ответ, если вы не хотите загрязнять тайник, вы можете просто создать новую ветку, вернуться к исходной ветке, выполнить сброс, а затем удалить вновь созданную ветку.
Вы можете создать псевдоним для stash save --keep-index --include-untracked и использовать тайник в качестве корзины, чтобы вы всегда могли легко восстановить свои изменения, если их очистка была ошибкой.
@ T.J.Crowder "Предупреждение, это приведет к безвозвратному удалению ваших файлов, если в вашем файле gitignore есть записи каталога / *." См. Этот пост: stackoverflow.com/questions/835501/…
Однажды я потерял кучу вещей из-за этого. Тайник не отслеживается.
git clean имеет вариант сухого хода, -n
Параметр save не рекомендуется в пользу git stash push. Он отличается от "stash push" тем, что не может принимать пути, а любые аргументы, не являющиеся опциями, формируют сообщение. git-scm.com
@WojtekOwczarczyk Итак, после использования stash save --keep-index --include-untracked: как вы восстановите изменения, если поймете, что очистка была ошибкой?
git stash save && git stash drop непригоден для использования в качестве общего сценария, поскольку он не будет работать (или делать неприятные вещи), если нечего хранить (и может потерять тайник, который вы, возможно, хотели сохранить). git checkout-index -afq && git clean -fdqx - это настоящая сделка!
Это проверяет текущий индекс для текущего каталога, отбрасывая все изменения в файлах из текущего каталога вниз.
git checkout .
или это, которое проверяет все файлы из индекса, перезаписывая файлы рабочего дерева.
git checkout-index -a -f
Привет, в чем разница между git checkout . и git checkout -- .?
@Evan: В этом случае никакой разницы.
@ Роберт Симер, а в общем случае?
@Evan: плохое место, чтобы задать этот вопрос. - Это не связано с вопросом ОП и не имеет отношения к ответу здесь.
+1 Это ПРАВИЛЬНЫЙ ОТВЕТ, поскольку он правильно обрабатывает случай, когда в некоторых файлах есть поэтапные и неэтапные изменения. Обратите внимание, что это решение ОТКАЗЫВАЕТ неустановленные изменения; если вы хотите сохранить их, вам следует использовать ответ git stash save --keep-index от @ greg-hewgill.
git checkout -- не работает, если у вас только одна ветка. git checkout . работает всегда.
Большое спасибо! Наконец ответ, который ВСЕГДА работает! Это может быть объединено с git clean для удаления неотслеживаемых файлов.
Если вас не интересует сохранение неустановленных изменений (особенно, если поэтапные изменения - это новые файлы), я нашел это удобным:
git diff | git apply --reverse
Пробовал все вышеперечисленные решения, но все еще не смог избавиться от новых неустановленных файлов.
Используйте git clean -f, чтобы удалить эти новые файлы - с осторожностью! Обратите внимание на параметр принудительной установки.
git clean -df
Очищает рабочее дерево, рекурсивно удаляя файлы, не находящиеся под контролем версий, начиная с текущего каталога.
-d: удаление неотслеживаемых каталогов в дополнение к неотслеживаемым файлам
-f: Force (может не понадобиться в зависимости от настройки clean.requireForce)
Запустите git help clean, чтобы увидеть руководство
почему за этот ответ проголосовали не все? ответил еще в 2011 году и до сих пор правильно.
Другой способ избавиться от новых файлов, который является более конкретным, чем git clean -df (он позволит вам избавиться от некоторых файлов, не обязательно от всех), - сначала добавить новые файлы в индекс, затем спрятать, а затем отбросить тайник.
Этот метод полезен, когда по какой-то причине вы не можете легко удалить все неотслеживаемые файлы каким-либо обычным механизмом (например, rm).
Я действительно нашел эту статью полезной для объяснения, когда какую команду использовать: http://www.szakmeister.net/blog/2011/oct/12/reverting-changes-git/
Есть несколько разных случаев:
Если вы не поставили файл, используйте
git checkout. Checkout «обновляет файлы в рабочем дереве, чтобы они соответствовали версии в индексе». Если файлы не были размещены (иначе добавлены в индекс) ... эта команда по существу вернет файлы к тому, что было вашей последней фиксацией.git checkout -- foo.txtЕсли вы поставили файл, используйте git reset. Сброс изменяет индекс в соответствии с фиксацией.
git reset -- foo.txt
Я подозреваю, что использование git stash - популярный выбор, поскольку он немного менее опасен. Вы всегда можете вернуться к нему, если случайно выбросите слишком много при использовании git reset. По умолчанию сброс выполняется рекурсивно.
Прочтите статью выше, чтобы получить дальнейшие советы.
Похоже, полное решение:
git clean -df
git checkout -- .
git clean удаляет все неотслеживаемые файлы (предупреждение: игнорируемые файлы, упомянутые непосредственно в .gitignore, он может удалять игнорируемые файлы, находящиеся в папках не удаляются), а git checkout удаляет все неустановленные изменения.
Два других ответа на самом деле не работают, а этот.
по какой-то причине это вернулось к предыдущей фиксации
@dval это потому, что первая команда удалила неиндексированные файлы, а вторая удалила неустановленные изменения (индексированных файлов). Поэтому, если у вас не было никаких поэтапных изменений, это то же самое, что вернуться к последней фиксации с git reset --hard.
используйте -dff, если неотслеживаемый каталог является клоном git.
Как понять эту команду? -- .? Говорит ли о проверке текущей последней фиксации в текущей папке?
Будьте осторожны, выполняя git clean -df. Если вы не понимаете, что он делает, возможно, вы удаляете файлы, которые хотите сохранить, например robots.txt, загруженные файлы и т. д.
Как сказал @ctlockey, первая команда также удалять каталоги, если они состоят только из игнорируемых файлов ... В моем проекте потеряна целая куча файлов конфигурации :( Будьте осторожны.
На самом деле это правильный ответ. stash and checkout применяется только для поэтапных изменений. git clean подойдет
@ctlockey, если они есть в вашем репозитории, у вас большие проблемы.
Два приведенных выше ответа не работают для неустановленных изменений, только этот.
Я подозреваю, что это работает там, где другие не работают, возможно, потому что в моем случае я удалил не только файлы, но и папки.
Эрорг !!! Я только что удалил папки проекта с помощью git clean -df? Как мне вернуть это? Пожалуйста помоги!!!! Я сделал команду ls, и я не вижу другую папку, которую я не собирался удалять
@ user2441441: вам не повезло: вы очистили файлы, которые не находились под контролем версий. Важные файлы должны находиться под контролем версий всегда (не обязательно как часть репозитория, в котором они находятся: вы можете поместить их в другой частный репозиторий и создать на них символическую ссылку). И файлы, которые находятся в рабочем каталоге репо, но не в версии, контролируемой этим репо, всегда должны быть .gitignored.
Я использую эти команды много лет. есть случай, когда ни один из них не работает. он просто продолжает говорить «изменения, не предназначенные для фиксации» и перечислять те же файлы. нет никаких ошибок, когда я убираю или оформляю заказ!
Вы должны находиться в корне репозитория git, чтобы это работало правильно.
Проголосовали против, так как это может удалить ваши файлы. Не надежное решение.
Чтобы понять и привыкнуть к тому, как работает git -df, я рекомендую добавить параметр n, если вы все еще новичок в выполнении команды, то есть git -dfn. Это запустит его в режиме dry-run, чтобы вы могли видеть, что будет удалено, без фактического удаления и каких-либо действий. Если вас устраивает результат, вы должны запустить его снова без опции n.
@Footniko, удаление неотслеживаемых файлов может быть частью желаемого поведения, в зависимости от того, что имелось в виду под «изменениями».
иногда нам нужно сохранить тестовые файлы, поэтому это решение опасно, мы вообще не хотим хранить в тайнике, и нам просто нужно, чтобы мы избегали команды stash для извлечения данных.
Хорошее объяснение git clean, варианты и использование: atlassian.com/git/tutorials/undoing-changes/git-clean
Один из моих любимых ответов на SO, к которому я возвращаюсь. Как и в том, что некоторые комментаторы упомянули выше, всему есть свое время и место. Мой лучший вариант использования для этого заключается в том, что я только что отправил рабочую версию на пульт, и теперь я начал работать над чем-то, что не должно увидеть свет, и я просто хочу вернуться к предыдущей версии и не возражать против всех изменения (файлы / каталоги) удаляются.
Этот ответ был ключевой частью моего ответа на Почему git не может выполнить жесткий / мягкий сброс по пути? / Как выполнить сброс git --hard / --soft по пути.
Обновление: git clean -df и git checkout-index -fa намного лучше. Я думаю, что git checkout-index -fa дает более желаемый результат, чем git checkout -- .. Я добавил эти команды с подробными пояснениями к своему ответу здесь: Как с помощью git сбросить рабочее дерево (состояние локальной файловой системы) до состояния индекса («поэтапные» файлы)?.
Если вы хотите передать тайник кому-то другому:
# add files
git add .
# diff all the changes to a file
git diff --staged > ~/mijn-fix.diff
# remove local changes
git reset && git checkout .
# (later you can re-apply the diff:)
git apply ~/mijn-fix.diff
[править] как прокомментировано, можно называть тайники. Что ж, используйте это, если хотите поделиться своим кошельком;)
На самом деле у Git stash может быть заголовок. Например git stash save "Feature X work in progress".
Это работает даже в каталогах, которые; за пределами обычных разрешений git.
sudo chmod -R 664 ./* && git checkout -- . && git clean -dfx
Случилось со мной недавно
Однако помните, что игнорируемый git контент не сохранит исходные разрешения! Следовательно, это может вызвать угрозу безопасности.
@twicejr Вы ошибаетесь, прочтите git help clean «-d Удалять неотслеживаемые каталоги в дополнение к неотслеживаемым файлам».
Почему вы установили для всех файлов режим чтения и записи? Не лучшая практика.
@Ghoti мой плохой, 664 правильный? вы также можете редактировать ответ.
Установка всех разрешений на 664 делает множество предположений о том, какие разрешения нужны проекту. Я думаю, что использование этой части команды вызовет проблемы у некоторых людей.
То, что далее следует, на самом деле является решением только в том случае, если вы работаете с вилкой репозитория, где вы регулярно синхронизируете (например, запрос на перенос) с другим репозиторием. Краткий ответ: удалить форк и рефорк, но прочтите предупреждения на github.
У меня была похожая проблема, возможно, не идентичная, и я с сожалением должен сказать, что мое решение не идеальное, но в конечном итоге оно эффективно.
Мне часто приходилось получать такие сообщения о статусе git (включая как минимум 2/4 файла):
$ git status
# Not currently on any branch.
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: doc/PROJECT/MEDIUM/ATS-constraint/constraint_s2var.dats
# modified: doc/PROJECT/MEDIUM/ATS-constraint/parsing/parsing_s2var.dats
#
# 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: doc/PROJECT/MEDIUM/ATS-constraint/constraint_s2Var.dats
# modified: doc/PROJECT/MEDIUM/ATS-constraint/parsing/parsing_s2Var.dats
Внимательный взгляд заметит, что в этих файлах есть доппельгангеры, которые представляют собой одну букву в случае выключения. Каким-то образом, и я понятия не имею, с чего я пошел по этому пути, чтобы начать (поскольку я сам не работал с этими файлами из исходного репозитория), я переключил эти файлы. Попробуйте многие решения, перечисленные на этой (и на других страницах), похоже, не помогли.
Я смог решить проблему, удалив свой разветвленный репозиторий и все локальные репозитории, а также переформатировав. Одного этого было недостаточно; upstream пришлось переименовать файлы, о которых идет речь, на новые имена файлов. До тех пор, пока у вас нет незавершенной работы, нет вики и проблем, которые расходятся с вышестоящим репозиторием, с вами все будет в порядке. Апстрим может быть вами не очень доволен, мягко говоря. Что касается моей проблемы, это, несомненно, ошибка пользователя, поскольку я не настолько разбираюсь в git, но тот факт, что исправить это далеко не просто, указывает на проблему с git.
git checkout -f
man git-checkout:
-f, --force
При переключении ветвей продолжайте, даже если индекс или рабочее дерево отличается от HEAD. Это используется для удаления локальных изменений.
При проверке путей из индекса не допускайте сбоев при несоединенных записях; вместо этого не объединенные записи игнорируются.
Это отменит изменения в индексе !! (И OP требует оставить их как есть.)
cd path_to_project_folder # take you to your project folder/working directory
git checkout . # removes all unstaged changes in working directory
Мой любимый
git checkout -p
Это позволяет выборочно возвращать фрагменты.
Смотрите также:
git add -p
Мне нравится возможность увидеть реальное изменение, прежде чем оно будет отброшено.
Это то, что я использую. git checkout -p, а затем «a», чтобы принять все.
Я никогда не думал об этом. -p добавляет хороший дополнительный уровень безопасности. Объедините его с git clean -d, чтобы на самом деле ответить OP.
Если все поэтапные файлы были фактически зафиксированы, то ветку можно просто сбросить, например. из вашего графического интерфейса примерно тремя щелчками мыши: Ответвляться, Перезагрузить, да!
То, что я часто делаю на практике, чтобы отменить нежелательные локальные изменения, - это зафиксировать все хорошие вещи, а затем сбросить ветку.
Если хороший материал зафиксирован в одном коммите, вы можете использовать «изменить последний коммит», чтобы вернуть его в состояние постановки или неустановки, если вы в конечном итоге захотите зафиксировать его немного по-другому.
Возможно, это не то техническое решение, которое вы ищете для своей проблемы, но я считаю его очень практичным решением. Он позволяет выборочно отбрасывать неустановленные изменения, сбрасывая изменения, которые вам не нравятся, и сохраняя те, которые вы делаете.
Итак, я просто делаю совершить, сброс ветки и изменить последнюю фиксацию.
просто скажи
git stash
Это удалит все ваши локальные изменения. Вы также можете использовать позже, сказав
git stash apply
или же git stash pop
Вместо того, чтобы отбрасывать изменения, я сбрасываю свой пульт в исходное состояние. Примечание. Этот метод предназначен для полного восстановления вашей папки до репо.
Поэтому я делаю это, чтобы убедиться, что они не сидят там, когда я git reset (позже - исключает gitignores в Origin / branchname)
ПРИМЕЧАНИЕ. Если вы хотите сохранить файлы, которые еще не отслеживаются, но не в GITIGNORE, вы можете пропустить этот шаг, так как он сотрет эти неотслеживаемые файлы, которых нет в вашем удаленном репозитории (спасибо @XtrmJosh).
git add --all
Затем я
git fetch --all
Затем я возвращаюсь в исходное состояние
git reset --hard origin/branchname
Это вернет все на круги своя. Точно так же, как ПОВТОРНОЕ Клонирование ветки, ПОКА все мои файлы с gitignored сохраняются локально и на месте.
Обновлено для каждого комментария пользователя ниже: Вариант для сброса на любую текущую ветку, в которой находится пользователь.
git reset --hard @{u}
Это мой предпочтительный вариант, но почему вы сначала добавляете все изменения? Насколько мне известно, это просто изменяет список каталогов в файлах Git, а при использовании git reset --hard это все равно будет потеряно, а каталоги все равно будут удалены.
Я не использую mac или linux, github windows powershell иногда оставляет файлы там после сброса. Я думаю, это потому, что git reset устанавливает все файлы в репо в исходное состояние. Если они не добавлены, они не будут затронуты. Затем настольный клиент получит сообщение «Привет, этот файл находится здесь, и его нужно зафиксировать».
Смысл сделан. Я не использую Windows, поэтому не видел этой проблемы (по крайней мере, не использовал Windows последние несколько месяцев, мало что помню до этого - это одно огромное прискорбное размытие). Возможно, стоит отметить обоснование в вашем основном ответе :)
Я столкнулся с этой проблемой и на Mac. Если файл не отслеживается в репозитории, иногда git reset его не трогает. Я не могу выделить «ПОЧЕМУ», но когда это произойдет, если я сделаю сброс, а у меня все еще останется один или два незафиксированных файла, я добавляю --all и снова сбрасываю --hard.
Если вы не зафиксировали или не поставили новый файл, git полностью его игнорирует и не трогает. Он не хочет случайно удалять то, что вам может понадобиться. Вы можете увидеть здесь на --untracked-files[=<mode>], что неотслеживаемые файлы отображаются по умолчанию в git status, и вы можете указать ему не показывать их, если это вас беспокоит! Для записи git add --all подготовит файлы для фиксации, после чего git распознает их (следовательно, git reset --hard будет работать). git clean удаляет неотслеживаемые файлы глянь сюда
Спасибо - так что в основном, если вы git add --all, вы можете сбросить или вам нужно git add --all, тогда получите чистый Guess clean - это несколько меньше символов;)
В значительной степени, хотя, если остались неотслеживаемые файлы, я обычно оставляю их в покое. Паранойя и все такое, заставляет меня думать, что я что-нибудь сломаю: D
Мне нравится небольшой приятный вариант - git reset --hard @{u}, который сбрасывает ветку туда, где находится текущая ветка удаленного отслеживания.
Вы можете использовать git stash - если что-то пойдет не так, вы все равно можете вернуться из тайника. Подобно другому ответу здесь, но этот также удаляет все неустановленные файлы, а также все неустановленные удаления:
git add .
git stash
Если вы проверите, что все в порядке, выбросьте тайник:
git stash drop
Ответ от Билала Максуда с git clean также сработал для меня, но с тайником у меня больше контроля - если я сделаю что-то случайно, я все равно могу вернуть свои изменения
ОБНОВИТЬ
Я думаю, есть еще одно изменение (не знаю, почему это сработало для меня раньше):
git add . -A вместо git add .
без -A удаленные файлы не будут размещены
Если у вас подмодуль и никакие другие решения не работают, попробуйте:
Чтобы проверить, в чем проблема (возможно, «грязный» случай), используйте:
git diffЧтобы удалить тайник
git submodule update
Ни одно из решений не работает, если вы просто изменили разрешения файла (это в DOS / Windoze)
Mon 23/11/2015-15:16:34.80 C:\...\work\checkout\slf4j+> git status
On branch SLF4J_1.5.3
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: .gitignore
modified: LICENSE.txt
modified: TODO.txt
modified: codeStyle.xml
modified: pom.xml
modified: version.pl
no changes added to commit (use "git add" and/or "git commit -a")
Mon 23/11/2015-15:16:37.87 C:\...\work\checkout\slf4j+> git diff
diff --git a/.gitignore b/.gitignore
old mode 100644
new mode 100755
diff --git a/LICENSE.txt b/LICENSE.txt
old mode 100644
new mode 100755
diff --git a/TODO.txt b/TODO.txt
old mode 100644
new mode 100755
diff --git a/codeStyle.xml b/codeStyle.xml
old mode 100644
new mode 100755
diff --git a/pom.xml b/pom.xml
old mode 100644
new mode 100755
diff --git a/version.pl b/version.pl
old mode 100644
new mode 100755
Mon 23/11/2015-15:16:45.22 C:\...\work\checkout\slf4j+> git reset --hard HEAD
HEAD is now at 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Added .gitignore
Mon 23/11/2015-15:16:47.42 C:\...\work\checkout\slf4j+> git clean -f
Mon 23/11/2015-15:16:53.49 C:\...\work\checkout\slf4j+> git stash save -u
Saved working directory and index state WIP on SLF4J_1.5.3: 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Added .gitignore
HEAD is now at 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Added .gitignore
Mon 23/11/2015-15:17:00.40 C:\...\work\checkout\slf4j+> git stash drop
Dropped refs/stash@{0} (cb4966e9b1e9c9d8daa79ab94edc0c1442a294dd)
Mon 23/11/2015-15:17:06.75 C:\...\work\checkout\slf4j+> git stash drop
Dropped refs/stash@{0} (e6c49c470f433ce344e305c5b778e810625d0529)
Mon 23/11/2015-15:17:08.90 C:\...\work\checkout\slf4j+> git stash drop
No stash found.
Mon 23/11/2015-15:17:15.21 C:\...\work\checkout\slf4j+> git checkout -- .
Mon 23/11/2015-15:22:00.68 C:\...\work\checkout\slf4j+> git checkout -f -- .
Mon 23/11/2015-15:22:04.53 C:\...\work\checkout\slf4j+> git status
On branch SLF4J_1.5.3
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: .gitignore
modified: LICENSE.txt
modified: TODO.txt
modified: codeStyle.xml
modified: pom.xml
modified: version.pl
no changes added to commit (use "git add" and/or "git commit -a")
Mon 23/11/2015-15:22:13.06 C:\...\work\checkout\slf4j+> git diff
diff --git a/.gitignore b/.gitignore
old mode 100644
new mode 100755
diff --git a/LICENSE.txt b/LICENSE.txt
old mode 100644
new mode 100755
diff --git a/TODO.txt b/TODO.txt
old mode 100644
new mode 100755
diff --git a/codeStyle.xml b/codeStyle.xml
old mode 100644
new mode 100755
diff --git a/pom.xml b/pom.xml
old mode 100644
new mode 100755
diff --git a/version.pl b/version.pl
old mode 100644
new mode 100755
Единственный способ исправить это - вручную сбросить разрешения для измененных файлов:
Mon 23/11/2015-15:25:43.79 C:\...\work\checkout\slf4j+> git status -s | egrep "^ M" | cut -c4- | for /f "usebackq tokens=* delims = " %A in (`more`) do chmod 644 %~A Mon 23/11/2015-15:25:55.37 C:\...\work\checkout\slf4j+> git status On branch SLF4J_1.5.3 nothing to commit, working directory clean Mon 23/11/2015-15:25:59.28 C:\...\work\checkout\slf4j+> Mon 23/11/2015-15:26:31.12 C:\...\work\checkout\slf4j+> git diff
Независимо от того, в каком состоянии находится ваше репо, вы всегда можете выполнить сброс к любой предыдущей фиксации:
git reset --hard <commit hash>
Это отменит все изменения, сделанные после этого коммита.
Это также отбросит все в индексе (а не только то, что не в индексе), что выходит за рамки того, что запрашивает OP.
Поскольку ни один ответ не предлагает точную комбинацию опций, которую я использую, вот она:
git clean -dxn . # dry-run to inspect the list of files-to-be-removed
git clean -dxf . # REMOVE ignored/untracked files (in the current directory)
git checkout -- . # ERASE changes in tracked files (in the current directory)
Это текст онлайн-справки для используемых опций git clean:
-d
Удалите неотслеживаемые каталоги в дополнение к неотслеживаемым файлам. Если неотслеживаемый каталог управляется другим репозиторием Git, он не удаляется по умолчанию. Дважды используйте параметр -f, если вы действительно хотите удалить такой каталог.
-x
Не используйте стандартные правила игнорирования, считываемые из .gitignore (для каждого каталога) и $GIT_DIR/info/exclude, но все же используйте правила игнорирования, указанные с параметрами -e. Это позволяет удалить все неотслеживаемые файлы, включая продукты сборки. Это можно использовать (возможно, вместе с git reset) для создания нетронутого рабочего каталога для тестирования чистой сборки.
-n
На самом деле ничего не удаляйте, просто покажите, что будет сделано.
-f
Если для переменной конфигурации Git clean.requireForce не задано значение false, Git clean откажется удалять файлы или каталоги, если не указано -f, -n или -i. Git откажется удалять каталоги в подкаталоге или файле .git, если не указан второй -f.
+1 за это решение. Что касается вашего замечания о том, что «git checkout. Необходимо выполнить в корне репозитория», возможно, вы могли бы упомянуть, что вместо этого мы можем просто сделать git reset --hard? (что на самом деле эквивалентно git reset --hard HEAD и должно работать независимо от текущего каталога ...)
Также в отношении первой команды git clean -dfx, вот совет, который я использую, чтобы быть в безопасности перед ее запуском: просто запустите git clean -d -x -n раньше, чтобы отобразить список файлов, которые необходимо удалить, затем подтвердите операцию, запустив git clean -d -x -f (I поместите аргумент -n или -f в конце, чтобы иметь возможность быстро изменить его в терминале)
Обратите внимание, что это необратимо, и если у вас есть файлы в .gitignore, вы потеряете их. Поэтому подумайте о резервном копировании вашего проекта перед этим.
@MartinG Я просто воспользовался возможностью включить свой двапредложения, включая тот, который добавляет шаг «пробного прогона» (лучше безопасно, чем сожалеть!). В любом случае, не стесняйтесь вносить поправки в мою правку, если это необходимо!
Когда вы набираете git status, (используйте "git checkout - ...", чтобы отменить изменения в рабочем каталоге) Показано.
например git checkout -- .
Проголосовали против, потому что это не помогает быстро удалить все файлы. Три точки означают, что вам необходимо перечислить все файлы. Это особенно плохо, если вам нужно сразу выбросить кучу файлов, например. во время большого слияния после того, как вы поставили все модификации, которые хотите сохранить
Конечно, правильная команда - «git checkout -». единственная точка. В комментарии три точки были грамматическими, чтобы указать, что есть много других вариантов, которые можно было использовать.
Я считаю,
git clean -df
должен сделать свое дело. Согласно Документация Git по git clean
git-clean - Remove untracked files from the working tree
Описание
Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.
Normally, only files unknown to Git are removed, but if the -x option is specified, ignored files are also removed. This can, for example, be useful to remove all build products.
If any optional ... arguments are given, only those paths are affected.
Опции
-d Remove untracked directories in addition to untracked files. If an untracked directory is managed by a different Git repository, it is not removed by default. Use -f option twice if you really want to remove such a directory.
-f --force If the Git configuration variable clean.requireForce is not set to false, git clean will refuse to run unless given -f, -n or -i.
Просто используйте:
git stash -u
Выполнено. Легко.
Если вы В самом деле заботитесь о своем стеке тайника, вы можете продолжить с git stash drop. Но в этот момент вам лучше использовать (от Мариуша Новака):
git checkout -- .
git clean -df
Тем не менее, мне больше всего нравится git stash -u, потому что он «отбрасывает» все отслеживаемые и неотслеживаемые изменения всего за одна команда. Однако git checkout -- . отбрасывает только отслеженные изменения,
и git clean -df отбрасывает только неотслеживаемые изменения ... и ввод обеих команд - это слишком много работы далеко :)
Примечание: git stash -u скоро (Git 2.14.x / 2.15, Q3 2017) немного изменится: stackoverflow.com/a/46027357/6309
Если я получаю вопрос о правильности OP, следует сохранить проиндексированные файлы. Следует удалять только неэтапные изменения. На мой взгляд, так и должен быть git stash -k.
Просто используйте:
git stash -k -u
Это сохранит неустановленные изменения и неотслеживаемые файлы (новые файлы) и сохранит промежуточные файлы.
Это лучше, чем reset / checkout / clean, потому что вы можете захотеть их вернуть позже (git stash pop). Лучше хранить их в тайнике, чем выбрасывать.
У меня была странная ситуация, когда файл всегда не размещался, это помогает мне решить.
git rm .gitattributes
git add -A
git reset --hard
Самый простой способ сделать это - использовать эту команду:
Эта команда используется для отмены изменений в рабочем каталоге -
git checkout -- .
https://git-scm.com/docs/git-checkout
В команде git сохранение неотслеживаемых файлов достигается с помощью:
git stash -u
http://git-scm.com/docs/git-stash
Дважды я приходил сюда, читал этот ответ и в конце забыл о .. Будущему мне: период существенный!
Мне нужно было избавиться от всех локальных изменений в подкаталоге, не отменяя всех остальных изменений. Этот ответ очень помог, спасибо
Пожалуйста, опишите, что делают две команды. Отсутствие объяснения действительно бесполезно.
отлично. касса делает за одну команду то, что самая популярная - за две. также можно использовать git clean -fd для очистки файлов не в индексе.
Вы можете создать свой собственный псевдоним, описывающий, как это сделать.
Я использую следующий псевдоним, чтобы отменить изменения.
Отменить изменения в (списке) файлов в рабочем дереве
discard = checkout --
Затем вы можете использовать его как следующее, чтобы отменить все изменения:
discard .
Или просто файл:
discard filename
В противном случае, если вы хотите отменить все изменения, а также неотслеживаемые файлы, я использую сочетание проверки и очистки:
Очистить и отменить изменения и неотслеживаемые файлы в рабочем дереве
cleanout = !git clean -df && git checkout -- .
Таким образом, использование простое, как следующее:
cleanout
Теперь он доступен в следующем репозитории Github, который содержит множество псевдонимов:
Если практически невозможно исключить модификации файлов, не рассматривали ли вы их игнорирование? Если это утверждение верно и вы не будете трогать эти файлы во время разработки, эта команда может быть полезна:
git update-index --assume-unchanged file_to_ignore
Если вы просто хотите удалить изменения в существующих файлах, используйте checkout (задокументировано здесь).
git checkout -- .
- Ветвь не указана, поэтому проверяется текущая ветка.
- Двойной дефис (
--) сообщает Git, что следующее следует рассматривать как второй аргумент (путь), что вы пропустили указание ветки. - Точка (
.) указывает все пути.
Если вы хотите удалить добавленные файлы с момента вашего последнего коммита, используйте clean (задокументировано здесь):
git clean -i
- Параметр
-iзапускает интерактивныйcleanдля предотвращения ошибочного удаления. - Несколько других вариантов доступны для более быстрого выполнения; см. документацию.
Если вы хотите переместить изменения в место хранения для последующего доступа, используйте stash (задокументировано здесь):
git stash
- Все изменения будут перемещены в Git's Stash для возможного доступа в дальнейшем.
- Несколько вариантов доступны для более тонкого хранения; см. документацию.
Это точно преобразует ваши изменения и отбросит недавно добавленные файлы из предыдущей фиксации.
он удалит только что добавленные файлы? или просто отменить изменения в старых неустановленных файлах?
Чтобы сделать безвозвратный сброс:
git reset --hard
Чтобы сохранить изменения на потом:
git stash
у вас есть очень простая команда git git checkout .
Обновление 2019
Теперь вы можете отменить неустановленные изменения в один отслеживаемый файл с помощью:
git restore <file>
и в все отслеживаемые файлы в текущем каталоге (рекурсивно) с:
git restore .
Если вы запустите последний из корня репо, он отменит неустановленные изменения во всех отслеживаемых файлах.
Примечания
git restoreбыл представлен в Июль 2019 г. и выпущен в версии 2.23 как часть разделения командыgit checkoutнаgit restoreдля файлов иgit switchдля ветвей.git checkoutпо-прежнему ведет себя так же, как и раньше, и более старые ответы остаются в силе.- При запуске
git statusс неустановленными изменениями в рабочем дереве теперь Git предлагает использовать именно это, чтобы отменить их (вместоgit checkout -- <file>, как это было до v2.23). - Как и в случае с
git checkout -- ., это отменяет только изменения в отслеживаемых файлах. Таким образом, Ответ Мариуша Новака по-прежнему применяется, и если вы хотите отменить все неустановленные изменения, включая неотслеживаемые файлы, вы можете запустить, как он предлагает, дополнительныйgit clean -df.
Я хотел отменить только мои неустановленные изменения, не затрагивая вновь добавленные файлы, чтобы git restore . работал отлично. Спасибо.
Я сделал git restore <filename>, и он работал отлично.
У меня сработало нормально.
Согласно странице руководства git restore . восстанавливает все файлы в текущем каталоге, а не во всем репозитории.
Ты прав. Спасибо! Я только что проверил, и это действительно так. Однако он рекурсивен. Таким образом, при запуске из корня проекта он применяется ко всему репозиторию. Отредактирую свой ответ.
@bob 2.23 github.com/git/git/blob/master/Documentation/RelNotes/…
Спасибо @Tycholiz. В то время, когда был задан вопрос и принят ответ, этой новой команды не существовало :) Так что логично, что это не принятый ответ :)
Должен быть принятый ответ в 2020 году!
Спасибо! Это меняет жизнь. Раньше делал git commit -m "wip" && git reset --hard && git reset --soft HEAD~1 && git reset.
Напоминаем, что в новых версиях git есть команда восстановления, которая также предлагается при вводе git status при изменении файлов:
(используйте "git add ...", чтобы обновить то, что будет зафиксировано)
(используйте "git restore ...", чтобы отменить изменения в рабочем каталоге)
Итак, git 'restore' - современное решение этой проблемы. Всегда полезно прочитать предложения от git после ввода git status :-)
Это просто повторить stackoverflow.com/a/57880896/6309.
Конечно, просто констатирую очевидное и что git пытается помочь с комментариями из вызова 'git status' :-)
См. Также stackoverflow.com/questions/22620393/…