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

Question

Следующим был статус моего репо.

[~/rails_apps/jekyll_apps/nepalonrails (design)⚡] ➔ gst
# On branch design
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   _layouts/default.html
#   deleted:    _site/blog/2010/04/07/welcome-to-niraj-blog/index.html
#   deleted:    _site/blog/2010/04/08/the-code-syntax-highlight/index.html
#   deleted:    _site/blog/2010/05/01/showing-demo-to-kalyan/index.html
#   deleted:    _site/config.ru
#   deleted:    _site/index.html
#   deleted:    _site/static/css/style.css
#   deleted:    _site/static/css/syntax.css
#   modified:   static/css/style.css
#
no changes added to commit (use "git add" and/or "git commit -a")

Кстати, я сделал git checkout -f, и теперь изменения пропали, чего я не должен был делать.

[~/rails_apps/jekyll_apps/nepalonrails (design)⚡] ➔ git co -f
[~/rails_apps/jekyll_apps/nepalonrails (design)] ➔ gst
# On branch design
nothing to commit (working directory clean)
[~/rails_apps/jekyll_apps/nepalonrails (design)] ➔ 

Могу ли я вернуть изменения обратно?

Answer 1

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

Answer 2

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

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

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

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

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

co = "!git stash push -m \"co backup\"; git stash apply; git checkout \"$@\"" 

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

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

---

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

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

---

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

---

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

---

Вот еще одна безумная идея: не запускайте 'git checkout ...' на грязном рабочем дереве. Проблема решена.
Еще один: не используйте имена файлов как имена филиалов.
Если честно: у меня та же проблема с неосторожными вызовами «rm», разрушающими мой день, но когда я бормочу проклятия, это происходит из-за моей лени / глупости, а не из-за завершений или поведения «rm» 1076 *

Answer 3

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

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

Answer 4

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

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

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

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

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

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

Answer 5

если вы используете Eclipse в качестве IDE и EGit , у вас есть в командном меню:

1. щелкните правой кнопкой мыши по файлу из
2. Элемент списка "Команда" -> "Показать локальную историю"

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

Answer 6

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

Answer 7

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