Получите обратно изменения после случайной проверки?

Ответ 1

Я не думаю, что вы можете восстановить эти личные данные ("частные", как в "не добавленные в индекс, так и не зафиксированные", так что неизвестно git), если у вас нет другого процесса резервного копирования для вашего текущего рабочего каталога.

Даже если это не было предложено на странице Git Aliases, я бы сказал, что для какого-либо псевдонима для проверки (например, используется alias rm/bin/rm -i):

[alias]
co = !sh -c 'git stash; git stash apply; git checkout "[email protected]"'

с " git stash; git stash apply git stash; git stash apply 'является "технологией контрольной точки", используемой Брайаном Кэмпбеллом в его ответе.

stason предлагает в комментариях:

co = "!git stash push -m \"co backup\"; git stash apply; git checkout \"[email protected]\"" 

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

Этот вопрос напоминает мне об обсуждении этого поведения в ycombinator (extracts):

Я потерял много данных с git.
Большинство из них связано с безобидными звучащими командами, которые не запрашивают подтверждения при удалении данных.
Например, git checkout filename эквивалентно svn revert filename.
Конечно, git checkout branchname делает что-то совершенно другое.
Если ветка и файл имеют одно и то же имя, git по умолчанию будет переключать ветки, но это не останавливает автозаполнение bash от разрушения дня.

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

Возможно, это раздражает, но это ошибка пользователя, а не ошибка дизайна. С git, если я хочу без потерь отказаться от своей рабочей копии, я могу просто " git stash ".
По вашей логике, "rm" ошибочен, потому что он не запрашивает подтверждение при передаче -f вместо -i. Ну, да. Сожалею.

Ваша аналогия была бы более точной, если бы rm somename был эквивалентом apt-get update, а rm othername rm -fr othername было rm -fr othername.
Тем не менее, не может быть прав, что " get checkout foo " делает одну из двух ПОЛНОСТЬЮ разных вещей в зависимости от того, есть ли файл с именем foo в текущем каталоге

Вот еще одна сумасшедшая идея: не запускайте " git checkout... " на грязном рабочем дереве. Задача решена.
Еще один: не используйте имена файлов как имена ветвей.
Честно говоря, у меня такая же проблема с неосторожными вызовами " rm ", разрушающих мой день, но когда я бормочу проклятия, это по моей ленивости/глупости, а не по завершению bash или поведению " rm ",

Ответ 2

Еще одна вещь, на которую вы можете обратить внимание, - через вашу среду IDE. Я случайно просмотрел 2 файла и смог вернуть изменения через "локальную историю" моей IDE (netbeans). Какое благословение!

Ответ 3

Если вы ранее не использовали git add или git stash с этими файлами, то, к сожалению, нет. Если вы добавили или спрятали их, то вы сможете найти их хэши через git reflog.

Мне никогда не нравилось это деструктивное поведение git checkout. Возможно, полезным улучшением будет то, что этот тип git checkout автоматически создаст stash (чтобы файлы были захвачены через reflog), прежде чем перезаписывать вашу работу.

Ответ 4

В случае, если вы используете vim для Linux, может применяться следующее.

• Если файлы открыты в активном буфере, то у вас есть содержимое файла, если вы не перезагружаете файл в vim и можете восстановить его, сохранив его. ,

• Если файлы не открыты в активном буфере, но являются грязными, тогда в исходном каталоге должен быть файл.swp, который также имеет копию содержимого, которое можно восстановить через vim -r file.swp.

• Если файлы не открыты в антивирусном буфере и не загрязнены, и если ваша рабочая копия находится в разделе ext3 или ext4, тогда extundelete может найти недавно удаленные.swp файлы и/или более старую версию исходных файлов. Перезагрузите раздел как прочитанный -o nly, например mount -o remount,ro/mnt/point и run

  extundelete --recover-directory /path/to/working/copy /dev/sdaX
  

  Если раздел, содержащий рабочую копию, является корневым разделом, он может отказаться от повторного подключения, а затем попытаться убить все службы и, если все еще не пойти, затем завершить работу и загрузить с помощью Live CD/USB/PXE, например GRML, и запустить выше. Таким образом, мне удалось восстановить один из трех потерянных файлов.

Ответ 5

если вы используете Eclipse в качестве IDE и EGit, у вас есть в файле Team-menu:

• щелкните правой кнопкой мыши на свой файл из
• Элемент списка "Команда" → "Показать локальную историю"

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

Ответ 6

Если IDE - это Android Studio, откройте файл, который был изменен, и перейдите в VCS → Local History → Show History. Там будет показан открытый файл.

Ответ 7

Вы ничего не можете сделать с командами git, но если вы используете IDE, вы можете восстановить свои изменения. Я использую PhpStorm, где мы можем увидеть историю изменений файла. Просто нажмите правой кнопкой мыши на файл и нажмите на локальную историю. На вкладке "Внешние изменения" вы можете найти локальные изменения, которые вы случайно удалили.

Ответ 8

Если вы используете IDE, и если у него есть опция отмены, просто отмените изменения, это отменит перезагрузку с диска, которая вернет ваши изменения. Большинство IDE/редакторов имеют эту опцию.

Ответ 9

Я использую Intellij. CTRL + z работает для меня, он предложит вам "перезагрузить изменения с диска", затем нажмите "Да".