Как отменить неустановленные изменения в Git?

Еще один более быстрый способ:

git stash save --keep-index --include-untracked

Вам не нужно включать --include-untracked, если вы не хотите вдаваться в подробности.

После этого вы можете сбросить этот тайник с помощью команды git stash drop, если хотите.

Для всех неустановленных файлов в текущем рабочем каталоге используйте:

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 clean -df
git checkout -- .

git clean удаляет все неотслеживаемые файлы (предупреждение: пока он выиграл » t удаляет игнорируемые файлы, упомянутые непосредственно в .gitignore, может удалять игнорируемые файлы, находящиеся в папках) и git checkout удаляет все неустановленные изменения.

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

git checkout .

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

git checkout-index -a -f

git clean -df

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

-d: Удалять неотслеживаемые каталоги в дополнение к неотслеживаемым файлам

-f: Force (может не понадобиться в зависимости от настройки clean.requireForce)

Запустите git help clean, чтобы просмотреть руководство

Обновление 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 checkout -p

Это позволяет выборочно возвращать фрагменты.

Смотрите также:

git add -p

Поскольку ни один ответ не предлагает точную комбинацию опций, которую я использую, вот она:

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.

Если вы просто хотите удалить изменения в существующих файлах, используйте checkout (задокументировано здесь).

git checkout -- .

• Ветвь не указана, поэтому проверяется текущая ветка.
• Двойной дефис (--) сообщает Git, что следующее следует рассматривать как его второй аргумент (путь), что вы пропустили указание ветки.
• Точка (.) указывает все пути.

Если вы хотите удалить файлы, добавленные с момента последней фиксации, используйте clean (задокументировано здесь):

git clean -i 

• Параметр -i запускает интерактивное clean, чтобы предотвратить ошибочное удаление.
• Несколько других вариантов доступны для более быстрого выполнения; см. документацию.

Если вы хотите переместить изменения в пространство хранения для последующего доступа, используйте stash (задокументировано здесь):

git stash

• Все изменения будут перемещены в Git's Stash для возможного последующего доступа.
• Несколько вариантов доступны для более тонкого хранения; см. документацию.

Я действительно нашел эту статью полезной для объяснения, когда какую команду использовать: http://www.szakmeister.net/blog/2011/oct/12/reverting-changes-git/

Есть несколько разных случаев:

1. Если вы не поставили файл, используйте git checkout. Checkout «обновляет файлы в рабочем дереве, чтобы они соответствовали версии в индексе». Если файлы не были добавлены в индекс (иначе говоря, добавлены в индекс) ... эта команда по существу вернет файлы к тому, что было вашей последней фиксацией.

   git checkout -- foo.txt

2. Если вы поставили файл, используйте git reset. Сброс изменяет индекс в соответствии с фиксацией.

   git reset -- foo.txt

Я подозреваю, что использование git stash - популярный выбор, поскольку он немного менее опасен. Вы всегда можете вернуться к нему, если случайно выбросите слишком много при использовании git reset. По умолчанию сброс выполняется рекурсивно.

Взгляните на статью выше для получения дополнительных советов.

Самый простой способ сделать это - использовать эту команду:

Эта команда используется для отмены изменений в рабочем каталоге -

git checkout -- .

https://git-scm.com/docs/git-checkout

В команде git сохранение неотслеживаемых файлов достигается с помощью:

git stash -u

http://git-scm.com/docs/git-stash

Если вы не заинтересованы в сохранении неустановленных изменений (особенно если поэтапные изменения - это новые файлы), я нашел это удобным:

git diff | git apply --reverse

Когда вы вводите git status, отображается (используйте «git checkout - ...», чтобы отменить изменения в рабочем каталоге).

e.g. git checkout -- .

git checkout -f

man git-checkout:

-f, --force

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

При проверке путей из индекса не допускайте сбоев при несоединенных записях; вместо этого не объединенные записи игнорируются.

Вы можете использовать git stash - если что-то пойдет не так, вы все равно можете вернуться из тайника. Подобно другому ответу здесь, но этот также удаляет все неустановленные файлы, а также все неустановленные удаления:

git add .
git stash

Если вы проверите, что все в порядке, выбросьте тайник:

git stash drop

Ответ Билала Максуда с git clean также сработал для меня, но с тайником у меня больше контроля - если я сделаю что-то случайно, я все равно могу вернуть свои изменения

ОБНОВЛЕНИЕ

Я думаю, есть еще одно изменение (не знаю, почему это сработало для меня раньше):

git add . -A вместо git add .

без -A удаленные файлы не будут размещены

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

Поэтому я делаю это, чтобы убедиться, что они не сидят там, когда я git reset (позже - исключает gitignores в Origin / branchname)

ПРИМЕЧАНИЕ. Если вы хотите сохранить файлы, которые еще не отслеживаются, но не в GITIGNORE, вы можете пропустить этот шаг, так как он сотрет эти неотслеживаемые файлы, которых нет в вашем удаленном репозитории (спасибо @XtrmJosh).

git add --all

Затем я

git fetch --all

Затем я возвращаюсь в исходное положение

git reset --hard origin/branchname

Это вернет все на круги своя. Точно так же, как ПОВТОРНОЕ Клонирование ветки, ПОКА все мои файлы с gitignored сохраняются локально и на месте.

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

git reset --hard @{u}

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

Используйте git clean -f для удаления этих новых файлов - с осторожностью! Обратите внимание на параметр принудительного выполнения.

Чтобы сделать безвозвратный сброс: git reset --hard

Чтобы сохранить изменения на потом: git stash

Просто используйте:

git stash -u

Выполнено. Легкий.

Если вы действительно заботитесь о своем стеке тайника, вы можете продолжить с git stash drop. Но в этот момент вам лучше использовать (от Мариуша Новака):

git checkout -- .
git clean -df

Тем не менее, мне нравится git stash -u больше всего, потому что он «отбрасывает» все отслеживаемые и неотслеживаемые изменения всего одной командой. Однако git checkout -- . отбрасывает только отслеженные изменения, а git clean -df отбрасывает только неотслеживаемые изменения ... и ввод обеих команд далеко слишком трудоемок :)

просто скажи

git stash

Это удалит все ваши локальные изменения. Вы также можете использовать позже, сказав

git stash apply 

или git stash pop

у вас очень простая команда git git checkout .

Это работает даже в каталогах, которые; за пределами обычных разрешений git.

sudo chmod -R 664 ./* && git checkout -- . && git clean -dfx

Случилось со мной недавно

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

git reset --hard <commit hash>

Это отменит все изменения, сделанные после этого коммита.

По моему мнению,

git clean -df

должен сделать свое дело. Согласно документации Git по git clean

git-clean - Удаляет неотслеживаемые файлы из рабочего дерева

Описание

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

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

Если указаны какие-либо необязательные аргументы ..., затрагиваются только эти пути.

Параметры

-d Удалить неотслеживаемые каталоги в дополнение к неотслеживаемым файлам. Если неотслеживаемый каталог управляется другим репозиторием Git, он не удаляется по умолчанию. Дважды используйте параметр -f, если вы действительно хотите удалить такой каталог.

-f --force Если для переменной конфигурации Git clean.requireForce не задано значение false, git clean откажется запускаться, если не задано -f, -n или -i.

Другой способ избавиться от новых файлов, который является более конкретным, чем git clean -df (он позволит вам избавиться от некоторых файлов, не обязательно от всех), - сначала добавить новые файлы в индекс, затем спрятать, а затем отбросить тайник.

Этот метод полезен, когда по какой-то причине вы не можете легко удалить все неотслеживаемые файлы каким-либо обычным механизмом (например, rm).

То, что далее следует, на самом деле является решением только в том случае, если вы работаете с вилкой репозитория, где вы регулярно синхронизируете (например, запрос на перенос) с другим репо. Краткий ответ: удалите fork и refork, но прочтите предупреждения на 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 rm .gitattributes
git add -A
git reset --hard

Если вы хотите передать тайник кому-то другому:

# 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

[править] как прокомментировано, можно называть тайники. Что ж, используйте это, если хотите поделиться своим кошельком;)

Вы можете создать собственный псевдоним, описывающий, как это сделать.

Я использую следующий псевдоним, чтобы отменить изменения.

Отменить изменения в (списке) файлов в рабочем дереве

discard = checkout --

Затем вы можете использовать его как следующий, чтобы отменить все изменения:

discard .

Или просто файл:

discard filename

В противном случае, если вы хотите отменить все изменения, а также неотслеживаемые файлы, я использую сочетание проверки и очистки:

Очистить и отменить изменения и неотслеживаемые файлы в рабочем дереве

cleanout = !git clean -df && git checkout -- .

Таким образом, использование простое, как следующее:

cleanout

Теперь он доступен в следующем репозитории Github, который содержит множество псевдонимов:

• https://github.com/GitAlias/gitalias

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

• Чтобы проверить, в чем проблема (возможно, «грязный» случай), используйте:

  git diff

• Чтобы удалить тайник

  git submodule update

Если все поэтапные файлы были фактически зафиксированы, то ветку можно просто сбросить, например. из графического интерфейса пользователя примерно тремя щелчками мыши: Переход, Сброс, Да!

То, что я часто делаю на практике, чтобы отменить нежелательные локальные изменения, - это зафиксировать все хорошие вещи, а затем сбросить ветку.

Если хороший материал зафиксирован в одной фиксации, вы можете использовать «изменить последнюю фиксацию», чтобы вернуть его в состояние постановки или неустановки, если вы в конечном итоге захотите зафиксировать его немного по-другому.

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

Таким образом, я просто выполняю фиксацию, сброс ветки и исправление последней фиксации.

Если практически невозможно исключить модификации файлов, не рассматривали ли вы их игнорирование? Если это утверждение верно и вы не будете трогать эти файлы во время разработки, эта команда может быть полезна:

git update-index --assume-unchanged file_to_ignore

Ни одно из решений не работает, если вы просто изменили разрешения для файла (это в 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 есть команда восстановления, которая также предлагается при вводе git status при изменении файлов:

(используйте git add ..., чтобы обновить то, что будет зафиксировано)

(используйте git restore ..., чтобы отменить изменения в рабочем каталоге)

Итак, git 'restore' - современное решение этой проблемы. Всегда полезно прочитать предложения от git после ввода git status :-)

Просто используйте:

git stash -k -u

Это сохранит неустановленные изменения и неотслеживаемые файлы (новые файлы) и сохранит подготовленные файлы.

Это лучше, чем _2 _ / _ 3 _ / _ 4_, потому что вы можете захотеть их вернуть позже (до git stash pop). Лучше хранить их в тайнике, чем выбрасывать.

Если вы хотите восстановить неустановленные файлы, используйте git restore --staged.