Возвратить изменения после случайного контроля?
Следующее было состоянием моего repo.
[~/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")
Accedently, я сделал 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)] ➔
Я могу возвратить изменения назад?
2 ответа
Я не думаю, что вы сможете восстановить эти личные данные («частные» как «не добавлены в индекс и не зафиксированы», поэтому неизвестны git), если у вас нет другого процесса резервного копирования для вашего текущего рабочего каталога.
Даже если это не предлагается на странице Git Aliases , я бы поспорил за какой-то псевдоним для проверки (например, есть псевдоним rm / bin / rm -i использование ):
[alias]
co = !sh -c 'git stash; git stash apply; git checkout "$@"'
с ' git stash; git stash apply 'является «техникой контрольных точек», использованной Брайаном Кэмпбеллом в его ответе .
Стейсон предлагает в комментариях :
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 испортить день.Вот безумная идея: если у вас есть безобидное действие и опасное действие, не помечайте их одной и той же командой.
Возможно, раздражает, но это ошибка пользователя, а не ошибка дизайна. С помощью git, если я хочу без потерь отказаться от своей рабочей копии, я могу просто «
git stash».
По вашей логике, "rm" ошибочна, потому что не запрашивает подтверждения, когда вы передаете-fвместо-i. Ну, да. Извините.
Ваша аналогия была бы более точной, если бы
rm somenameбыл эквивалентомapt-get update, аrm othernameбылrm -fr othername.
Тем не менее, не может быть правильным, что "get checkout foo" выполняет одно из двух СОВЕРШЕННО разных действий в зависимости от того, есть ли в текущем каталоге файл с именем foo
Вот еще одна безумная идея: не запускайте '
git checkout ...' на дереве грязной работы.Задача решена.
Еще один: не используйте повторно имена файлов в качестве имен веток.
Честно говоря: у меня та же проблема с небрежными вызовами 'rm', портящими мне день, но когда я бормочу проклятия, это происходит из-за моей лени / глупости, а не из-за завершения bash или поведения 'rm'
Если вы раньше не использовали git add или git stash с этими файлами, то, к сожалению, нет. Если вы добавили или спрятали их, вы сможете найти их хэши с помощью git reflog .
Мне никогда не нравилось такое деструктивное поведение git checkout . Возможно, полезным усовершенствованием было бы, чтобы этот вид git checkout автоматически создавал тайник (чтобы файлы записывались через журнал ссылок) перед перезаписью вашей работы.