В iPhone пропали настройки
Когда пропадают настройки на iPhone, не стоит переживать, считая, что они удалились насовсем. Когда память телефона становится слишком перегруженной, операционная система автоматически стирает иконку с рабочего стола. Также виной может быть человеческий фактор. Например, вы случайно переместили их в другую папку, а теперь не можете найти.

Вернуть системное приложение легко. Сперва смахните «Spotlight» и введите название, после этого при необходимости закрепите настройки на рабочем столе. Ещё один вариант – сделать запрос у голосового помощника «Siri». Не исключается возможность технической ошибки, для исправления которой достаточно перезагрузить айфон. Не стоит забывать о необходимости постоянно обновлять iOS, чтобы функции смартфона никогда не ограничивались.
Возврат к настройкам по умолчанию на iPhone
Данный шаг поможет не только вернуть пропавшее, но и восстановить первоначальный порядок приложений, как при покупке. Для осуществления не нужно устанавливать посторонние приложения, достаточно зайти в «Настройки», открыть «Основные» и выбрать «Сбросить настройки Домой». Предварительно скопируйте и перенесите важные файлы и документы, так как они могут утеряться в процессе, или же зарезервируйте их.
Если вы хорошо помните пароль от учётной записи Apple ID, то можете воспользоваться сервисом iCloud.com. После ввода данных выберите «Стереть iPhone» и подтвердите действие. Не забудьте заранее выполнить синхронизацию с iTunes, чтобы ничего не утратить.
Восстановление потерянных файлов на Windows 10
Если вы не можете найти потерянный файл из резервной копии, можно использовать Windows File Recovery, которое является приложением командной строки, доступным в Microsoft Store. Используйте это приложение, чтобы попытаться восстановить потерянные файлы, которые были удалены с локального запоминающего устройства (включая внутренние диски, внешние диски и USB-устройства) и которые не могут быть восстановлены из корзины. Восстановление в облачном хранилище и сетевых общих папках не поддерживается.
ПримечаниеДля этого приложения требуется Windows 10 сборка 19041 или более поздняя (см. версию Windows 10).
Важно: Если вы хотите увеличить вероятность восстановления файла, сведите к минимуму или избежать использования компьютера. В файловой системе Windows пространство, используемое удаленным файлом, помечается как свободное место, что означает, что файловые данные по-прежнему могут существовать и быть восстановлены. Но любое использование компьютера может создавать файлы, которые могут переписать это свободное пространство в любое время.
Windows File Recovery — выпуск зимы 2020 г.
Основные действия
- При необходимости скачайте и запустите приложение из Microsoft Store.
- Нажмите клавишу Windows, введите Windows File Recovery в поле поиска и выберите Windows File Recovery.
- Когда вам будет предложено разрешить приложению вносить изменения в устройство, нажмите кнопку Да.
- В окне командной строки введите команду в следующем формате: winfr source-drive: destination-drive: [/mode] [/switches]
- Существует два основных режима, которые можно использовать для восстановления файлов: Обычный и Расширенный. Примеры регулярного режима Восстановите папку Documents с диска C: в папку восстановления на диске E: . Не забудьте обратную косую черту (\) в конце папки. Winfr C: E: /regular /n \Users\\Documents\ Восстановление ФАЙЛОВ PDF и Word с диска C: в папку восстановления на диске E:. Winfr C: E: /regular /n *.pdf /n *.docx Примеры расширенного режима Восстановите любой файл со строкой «счет» в имени файла, используя подстановочные знаки. Winfr E: C: /extensive /n *invoice* Восстановите фотографии jpeg и png из папки «Изображения» в папку восстановления на диске E: . Winfr C: E: /extensive /n \Users\\Pictures\*.JPEG /n\Users\\Pictures\*.PNG Исходный и целевой диски должны отличаться. При восстановлении с диска операционной системы (часто C: ) используйте параметры /n , чтобы указать пользовательские файлы или папку.
Корпорация Майкрософт автоматически создает папку восстановления для вызываемого вами Recovery_ на целевом диске. - При появлении запроса на подтверждение продолжения введите Y, чтобы начать операцию восстановления. В зависимости от размера исходного диска это может занять некоторое время. Чтобы остановить процесс восстановления, нажмите клавиши CTRL + C.
Сведения о режимах и файловой системе
Следующие сведения помогут вам решить, какую файловую систему у вас есть и какой режим использовать.
Файловые системы
«Файловая система»
SD-карты, флэш-накопители или USB-накопители (< 4 ГБ)
Компьютеры (HDD, SSD), внешние жесткие диски, флэш-накопители или USB-накопители (> 4 ГБ)
Windows поддерживает несколько файловых систем, которые зависят от запоминающего устройства или операционной системы. Восстановление файлов из файловых систем, отличных от NTFS, поддерживается только в расширенном режиме. Чтобы узнать, какая файловая система у вас есть, щелкните правой кнопкой мыши диск в проводник и выберите Свойства.
Выбор режима для использования
Используйте следующую таблицу, чтобы решить, какой режим следует использовать. Если вы не уверены, начните с обычного режима.
Удалено некоторое время назад
После форматирования диска
Синтаксис командной строки
Общий синтаксис
В следующей таблице приведены сведения о том, для чего используется каждый расширенный коммутатор.
Параметр или переключатель
Поддерживаемые режимы
Указывает запоминающее устройство, на котором были потеряны файлы. Должен отличаться от целевого диска.
Указывает запоминающее устройство и папку, в которую будут помещены восстановленные файлы. Должен отличаться от исходного диска.
Обычный режим— стандартный вариант восстановления для не поврежденных дисков NTFS.
Расширенный режим— вариант тщательного восстановления, подходящий для всех файловой системы.
Сканирует определенный файл с помощью имени файла, пути к файлу, типа файла или подстановочных знаков. Например:
- Имя файла: /n myfile.docx
- Путь к файлу: /n /users//Documents/
- Подстановочный знак: /n myfile.*
- /n *.docx
- /n **
Сводка синтаксиса и параметров для общих пользователей.
Сводка синтаксиса и параметров для опытных пользователей.
Расширенный синтаксис
В следующей таблице приведены сведения о том, для чего используется каждый расширенный коммутатор.
Поддерживаемые режимы
Режим NTFS— быстрый вариант восстановления для работоспособных дисков NTFS с помощью таблицы файлов master
Режим сегментов, параметр восстановления для дисков NTFS с использованием сегментов записей файлов
Режим сигнатуры, параметр восстановления для всех типов файловой системы с использованием заголовков файлов
Восстановление определенных групп расширений, разделенных запятыми
Группы расширений режима подписи и поддерживаемые типы файлов.
Сохраняет файл журнала операции восстановления в расположении, отличном от расположения по умолчанию на диске восстановления (например, D:\logfile).
Переопределяет запросы пользователей, что полезно в файле скрипта.
Восстанавливает незавершенные файлы, например из корзины.
Восстанавливает системные файлы.
Указывает, следует ли всегда (a), никогда (n) или хозяйничать всегда(b) при выборе варианта перезаписи файла. Действие по умолчанию — запрос на перезапись.
Восстанавливает файлы без основных потоков данных.
Чтобы обеспечить управляемость результатов и сосредоточиться на пользовательских файлах, некоторые типы файлов фильтруются по умолчанию, но этот параметр удаляет этот фильтр. Полный список файлов этих типов см. в этой таблице.
Указывает, какие типы файлов фильтруются. Полный список файлов этих типов см. в этой таблице.
Указывает количество секторов на исходном устройстве. Чтобы найти сведения о секторе, используйте fsutil.
Указывает размер кластера (единицу выделения) на исходном устройстве.
Список фильтров расширений файлов
Следующие типы файлов фильтруются по результатам по умолчанию. Используйте параметр /e, чтобы отключить этот фильтр, или расширение /e:<> фильтр, чтобы указать типы файлов, которые не следует фильтровать.
_, admx, admx, appx, appx, ascx, asm, aspx, aux, ax, bin, browser, c, cab, cat cdf-ms, catalogItem, cdxm, cmake, cmd, coffee, config, cp, cpp, cs, cshtm, css, cur, dat, dll, et, evtx, exe, fon, gpd, h, hbakedcurve, htm, htm, ico, id, ildl, ilpdb, iltoc, iltocpdb, in, inf, inf_loc, ini, js, json, lib, lnk, log, man, manifest, map, metadata, mf, mof, msc, msi, mui, mum, mun, nls, npmignore, nupkg, nuspec, obj, p7s, p7x, pak, pckdep, pdb, pf, pkgdef, plist, pnf, pp, pri, props, ps1, ps1xm, psd1, psm1, py, resjson, resw, resx, rl, rs, sha512, snippet, sq, sys, t4, targets, th, tlb, tmSnippet, toc, ts, tt, ttf, vb, vbhtm, vbs, vsdir, vsix, vsixlangpack, vsixmanifest, vstdir, vstemplate, vstman, winmd, xam, xbf, xm, xrm-ms, xs, xsd, ym
Вопросы и ответы
Можете ли вы дать несколько советов, которые помогут мне использовать правильный синтаксис?
- Всегда используйте буквы диска в исходном и целевом пути, не забывайте двоеточие (:) после буквы диска и убедитесь, что между источником и назначением есть пробел.
- При указании только имени папки, например /n \Myfolder\, добавьте обратную косую черту (\) в ее конце.
- Если имя файла или папки содержит пробелы, заключите его кавычками. Например:
winfr C: E: /regular /n «\Users\\Documents\Quarterly Statement.docx»
Что означает в примерах команд?
В адресной строке проводник введите C:\users, чтобы просмотреть список потенциальных пользователей на компьютере. На вашем компьютере может быть несколько пользователей, включая вас, администратора и учетную запись по умолчанию. Если в пути к файлу отображается , это заполнитель для текущего имени пользователя на компьютере.
Почему я получаю следующее сообщение: «Источник и назначение не могут ссылаться на одну и ту же физическую секцию?»
Исходный и целевой диск или путь к секции не должны совпадать. Если у вас есть только один диск, используйте USB-диск или внешний жесткий диск в качестве пути назначения. Не создавайте секцию после потери данных, так как это снижает вероятность успешного восстановления.
Почему операция восстановления занимает так много времени?
В зависимости от размера диска восстановление файла может занять некоторое время, особенно если вы используете расширенный режим.
Почему с диска операционной системы восстанавливаются дополнительные файлы?
В фоновом режиме Windows постоянно создает и удаляет файлы. По умолчанию Windows File Recovery фильтрует эти файлы, но некоторые из них проскальзывают. Чтобы избежать этого, используйте> фильтра /n
Что такое папка $Recycle.Bin?
В режимах NTFS и сегментирования также могут отображаться потерянные файлы, восстановленные из корзины (файлы в корзине или которые были удалены без возможности восстановления) с именем $files.xxx и сохраненные в папке с именем $RECYCLE. БЕН.
Что произойдет, если целевой диск заполнен?
Если появится следующее сообщение: «Целевой диск заполнен, освободите место перед возобновлением: (R)esume, (S)kip-файл или (A)борт», освободите место на целевом диске, а затем выберите один из вариантов.
Мне не удалось восстановить файл, что теперь?
Если вы использовали обычный режим, повторите попытку в расширенном режиме, если поддерживается тип файла. Вполне возможно, что свободное пространство было перезаписано, особенно на твердотельных накопителях (SSD). Если вам нужна помощь, обратитесь к администратору.
Windows File Recovery — выпуск летом 2020 г.
Основные действия
- При необходимости скачайте и запустите приложение из Microsoft Store.
- Нажмите клавишу Windows, введите Windows File Recovery в поле поиска и выберите Windows File Recovery.
- Когда вам будет предложено разрешить приложению вносить изменения в устройство, нажмите кнопку Да.
- В окне командной строки введите команду в следующем формате:
| winfr source-drive: destination-drive: [/switches] |
Исходный и целевой диски должны отличаться. При восстановлении с диска операционной системы (часто C: ) используйте параметр /n и параметр /y:, чтобы указать пользовательские файлы или папку.
Корпорация Майкрософт автоматически создает папку восстановления для Recovery_<> даты и времени на целевом диске.
Для восстановления файлов можно использовать три режима: по умолчанию, сегмент и подпись.
режима по умолчанию Восстановите определенный файл с диска C: в папку восстановления на диске E: .
| winfr C: E: /n \Users\\Documents\QuarterlyStatement.docx |
Восстановите фотографии jpeg и png из папки «Изображения» в папку восстановления на диске E: .
| winfr C: E: /n \Users\\Pictures\*.JPEG /n \Users\\Pictures\*.PNG |
Восстановите папку Documents с диска C: в папку восстановления на диске E: .
| winfr C: E: /n \Users\\Documents\ |
Не забудьте обратную косую черту (\) в конце папки.
Примеры режима сегментирования (/r)
Восстановление ФАЙЛОВ PDF и Word с диска C: в папку восстановления на диске E:.
| winfr C: E: /r /n *.pdf /n *.docx |
Восстановите любой файл со строкой «счет» в имени файла, используя подстановочные знаки.
| winfr C: E: /r /n *invoice* |
Примеры режима подписи (/x)
При использовании режима подписи полезно сначала просмотреть поддерживаемые группы расширений и соответствующие типы файлов.
Восстановите фотографии JPEG (jpg, jpeg, jpe, jif, jfif, jfi) и PNG с диска C: в папку восстановления на диске E:.
| winfr C: E: /x /y:JPEG,PNG |
Восстановление ZIP-файлов (ZIP, docx, xlsx, ptpx и т. д.) с диска C: в папку восстановления на диске E:.
| winfr C: E:\RecoveryTest /x /y:ZIP |
В зависимости от размера исходного диска это может занять некоторое время.
Сведения о режимах и файловой системе
Следующие сведения помогут вам решить, какую файловую систему у вас есть и какой режим использовать.
Файловые системы
Windows поддерживает несколько файловых систем, которые зависят от запоминающего устройства или операционной системы. Восстановление файлов из файловых систем, отличных от NTFS, поддерживается только в режиме подписи. Чтобы узнать, какая файловая система у вас есть, щелкните правой кнопкой мыши диск в проводник и выберите Свойства.
«Файловая система»
SD-карты, флэш-накопители или USB-накопители (< 4 ГБ)
Windows Server и Windows Pro для рабочих станций
Компьютеры (HDD, SSD), внешние жесткие диски, флэш-накопители или USB-накопители (> 4 ГБ)
Выбор режима для использования
Используйте следующую таблицу, чтобы решить, какой режим следует использовать. Если вы не уверены, начните с режима по умолчанию.
«Файловая система»
Обстоятельствах
Рекомендуемый режим
Удалено некоторое время назад
Сегмент, за которым следует подпись
После форматирования диска
Сегмент, за которым следует подпись
Сегмент, за которым следует подпись
Поддерживается тип файла восстановления (см. следующую таблицу).
Группы расширений и типы файлов режима подписи
В следующей таблице перечислены группы расширений и поддерживаемые типы файлов для каждой группы при использовании параметра /y:
Группа расширений
jpg, jpeg, jpe, jif, jfif, jfi
mpeg, mp4, mpg, m4a, m4v, m4b, m4r, mov, 3gp, qt
zip, docx, xlsx, pptx, odt, ods, odp, odg, odi, odf, odc, odm, ott, otg, otp, ots, otc, oti, otf, oth
Синтаксис командной строки
Общий синтаксис
В следующей таблице приведены сведения о том, для чего используется каждый базовый параметр командной строки и переключатель.
Параметр или переключатель
Поддерживаемые режимы
Указывает запоминающее устройство, на котором были потеряны файлы. Должен отличаться от целевого диска.
Указывает запоминающее устройство и папку, в которую будут помещены восстановленные файлы. Должен отличаться от исходного диска.
Использует режим сегментов, который проверяет сегменты записи файла (FRS).
Сканирует конкретный файл с помощью имени файла, пути к файлу или подстановочных знаков. Например:
- Имя файла: /n myfile.docx
- Путь к файлу: /n /users//Documents/
- Подстановочный знак: /n myfile.*
/n *.docx
/n **
По умолчанию
Сегмента
Использует режим подписи, который проверяет типы файлов и работает во всех файловых системах.
Проверяет наличие файлов с определенными типами файлов. Разделите несколько записей с помощью запятых. Список групп расширений и соответствующих типов файлов см. в таблице «Группы расширений и типы файлов в режиме подписи» раздела «О режимах и файловых системах».
Показывает группы расширений режима подписи и соответствующие типы файлов в каждой группе.
Краткое описание синтаксиса и параметров для пользователей.
Краткое описание синтаксиса и параметров для опытных пользователей.
Расширенный синтаксис
В следующей таблице приведены сведения о том, для чего используется каждый расширенный коммутатор.
Поддерживаемые режимы
Сохраняет файл журнала операции восстановления в расположении, отличном от расположения по умолчанию на диске восстановления (например, D:\logfile).
Переопределяет запросы пользователей, что полезно в файле скрипта.
Восстанавливает незавершенные файлы, например из корзины.
По умолчанию
Сегмента
Восстанавливает системные файлы.
По умолчанию
Сегмента
Указывает, следует ли всегда (a), никогда (n) или хозяйничать всегда(b) при выборе варианта перезаписи файла. Действие по умолчанию — запрос на перезапись.
По умолчанию
Сегмента
Восстанавливает файлы без основных потоков данных.
По умолчанию
Сегмента
Чтобы обеспечить управляемость результатов и сосредоточиться на пользовательских файлах, некоторые типы файлов фильтруются по умолчанию, но этот параметр удаляет этот фильтр. Полный список файлов этих типов см. в этой таблице.
По умолчанию
Сегмента
Указывает, какие типы файлов фильтруются. Полный список файлов этих типов см. в этой таблице.
По умолчанию
Сегмента
Указывает количество секторов на исходном устройстве. Чтобы найти сведения о секторе, используйте fsutil.
Указывает размер кластера (единицу выделения) на исходном устройстве.
Первый сектор для сканирования на исходном устройстве.
Вопросы и ответы
Можете ли вы дать несколько советов, которые помогут мне использовать правильный синтаксис?
Ниже приведены некоторые рекомендации.
- Всегда используйте буквы диска в исходном и целевом пути, не забывайте двоеточие (:) после буквы диска и убедитесь, что между источником и назначением есть пробел.
- Если переключатель имеет двоеточие, например /y:, не добавляйте пробел между двоеточием и остальной частью значения.
- При указании только имени папки, например /n \Myfolder\, добавьте обратную косую черту (\) в ее конце.
- Если имя файла или папки содержит пробелы, заключите его кавычками. Например: winfr C: E: /n «\Users\\Documents\Quarterly Statement.docx»
- Чтобы остановить процесс восстановления, нажмите клавиши CTRL+C.
Что означает в примерах команд?
В адресной строке проводник введите C:\users, чтобы просмотреть список потенциальных пользователей на компьютере. На вашем компьютере может быть несколько пользователей, включая вас, администратора и учетную запись по умолчанию. Если в пути к файлу отображается , это заполнитель для текущего имени пользователя на компьютере.
Почему я получаю следующее сообщение: «Источник и назначение не могут ссылаться на одну и ту же физическую секцию?»
Исходный и целевой диск или путь к секции не должны совпадать. Если у вас есть только один диск, используйте USB-диск или внешний жесткий диск в качестве пути назначения. Не создавайте секцию после потери данных, так как это снижает вероятность успешного восстановления.
Почему операция восстановления занимает так много времени?
В зависимости от размера диска восстановление файла может занять некоторое время, особенно если используется режим подписи.
Почему с диска операционной системы восстанавливаются дополнительные файлы?
В фоновом режиме Windows постоянно создает и удаляет файлы. По умолчанию Windows File Recovery фильтрует эти файлы, но некоторые из них проскальзывают. Чтобы избежать этого, используйте параметр /n в режимах по умолчанию и сегментации, а параметр /y: в режиме подписи.
Что такое папка $Recycle.Bin?
В режиме по умолчанию и режиме сегментирования вы также можете увидеть потерянные файлы, восстановленные из корзины (файлы в корзине или которые были удалены без возможности восстановления) с именем $files.xxx и сохраненные в папке с именем $RECYCLE. БЕН.
Что произойдет, если целевой диск заполнен?
Если отображается следующее сообщение: «Целевой диск заполнен, освободите место перед возобновлением: (R)esume, (S)kip-файл или (A)bort», освободите место на целевом диске, а затем выберите один из вариантов.
Мне не удалось восстановить файл, что теперь?
Если вы использовали режим по умолчанию или сегмент, повторите попытку в режиме подписи, если поддерживается тип файла. Возможно, что свободное пространство было переопределино, особенно на твердотельном диске (SSD). Если вам нужна помощь, обратитесь к администратору.
10.7 Git изнутри — Обслуживание репозитория и восстановление данных
Изредка вам потребуется делать «уборку» — сделать репозиторий более компактным, очистить импортированный репозиторий от лишних файлов или восстановить потерянные данные. Данный раздел охватывает некоторые из этих сценариев.
Обслуживание репозитория
Время от времени Git выполняет автоматическую сборку мусора. Чаще всего эта команда ничего не делает. Однако, если у вас накопилось слишком много «рыхлых» объектов (не в pack-файлах), или, наоборот, отдельных pack-файлов, Git запускает полноценный сборщик — git gc (здесь «gc» это сокращение от «garbage collect», что означает «сборка мусора»). Эта команда выполняет несколько действий: собирает все «рыхлые» объекты и упаковывает их в pack-файлы; объединяет несколько упакованных файлов в один большой; удаляет недостижимые объекты, хранящиеся дольше нескольких месяцев.
Сборку мусора можно запустить вручную следующим образом:
$ git gc --auto
Опять же, как правило, эта команда ничего не делает. Нужно иметь примерно 7000 несжатых объектов или более 50 pack-файлов, чтобы запустился настоящий gc . Эти значения можно изменить с помощью параметров gc.auto и gc.autopacklimit соответственно.
Ещё одно действие, выполняемое gc — упаковка ссылок в единый файл. Предположим, репозиторий содержит следующие ветки и теги:
$ find .git/refs -type f .git/refs/heads/experiment .git/refs/heads/master .git/refs/tags/v1.0 .git/refs/tags/v1.1
Если выполнить git gc , эти файлы будут удалены из каталога refs . Git перенесёт их в файл .git/packed-refs в угоду эффективности:
$ cat .git/packed-refs # pack-refs with: peeled fully-peeled cac0cab538b970a37ea1e769cbbde608743bc96d refs/heads/experiment ab1afef80fac8e34258ff41fc1b867c702daa24b refs/heads/master cac0cab538b970a37ea1e769cbbde608743bc96d refs/tags/v1.0 9585191f37f7b0fb9444f35a9bf50de191beadc2 refs/tags/v1.1 ^1a410efbd13591db07496601ebc7a059dd55cfe9
При обновлении ссылки Git не будет редактировать этот файл, а добавит новый файл в refs/heads . Для получения хеша, соответствующего нужной ссылке, Git сначала проверит наличие файла ссылки в каталоге refs , а к файлу packed-refs обратится только в случае отсутствия оного. Так что, если вы не можете найти ссылку в каталоге refs , скорее всего она упакована в файле packed-refs .
Обратите внимание, последняя строка файла начинается с ^ . Это означает, что предыдущая строка является аннотированным тегом, а текущая строка — это коммит, на который указывает аннотированный тег.
Восстановление данных
В какой-то момент при работе с Git вы можете нечаянно потерять коммит. Как правило, такое случается, когда вы удаляете ветку, в которой находились некоторые наработки, а потом оказывается, что они всё-таки были нужными; либо вы выполнили git reset —hard , тем самым отказавшись от коммитов, которые затем понадобились. Как же в таком случае вернуть свои коммиты обратно?
Ниже приведён пример, в котором мы сбрасываем ветку master с потерей данных до более раннего состояния, а затем восстанавливаем потерянные коммиты. Для начала, давайте посмотрим, как сейчас выглядит история изменений:
$ git log --pretty=oneline ab1afef80fac8e34258ff41fc1b867c702daa24b Modify repo.rb a bit 484a59275031909e19aadb7c92262719cfcdf19a Create repo.rb 1a410efbd13591db07496601ebc7a059dd55cfe9 Third commit cac0cab538b970a37ea1e769cbbde608743bc96d Second commit fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit
Теперь сбросим ветку master на третий коммит:
$ git reset --hard 1a410efbd13591db07496601ebc7a059dd55cfe9 HEAD is now at 1a410ef Third commit $ git log --pretty=oneline 1a410efbd13591db07496601ebc7a059dd55cfe9 Third commit cac0cab538b970a37ea1e769cbbde608743bc96d Second commit fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit
Итак, теперь два последних коммита по-настоящему потеряны — они не достижимы ни из одной ветки. Необходимо найти SHA-1 хеш последнего коммита и создать ветку, указывающую на него. Сложность в том, чтобы узнать этот самый SHA-1, ведь вряд ли вы его запомнили, да?
Зачастую самый быстрый способ — использование команды git reflog . Дело в том, что во время вашей работы Git записывает все изменения HEAD. Каждый раз при переключении веток и коммитов изменений, добавляется запись в reflog. reflog также обновляется командой git update-ref — это, кстати, хорошая причина использовать именно эту команду, а не вручную записывать SHA-1 в ref-файлы, как было показано в Ссылки в Git. Вы можете посмотреть где находился указатель HEAD в любой момент времени, запустив git reflog :
$ git reflog 1a410ef HEAD@: reset: moving to 1a410ef ab1afef HEAD@: commit: Modify repo.rb a bit 484a592 HEAD@: commit: Create repo.rb
Здесь мы видим два коммита, на которые когда-то указывал HEAD, однако информации не так уж и много. Для получения информации в более удобном виде, можно воспользоваться командой git log -g , которая выведет лог записей из reflog в привычном формате:
$ git log -g commit 1a410efbd13591db07496601ebc7a059dd55cfe9 Reflog: HEAD@ (Scott Chacon ) Reflog message: updating HEAD Author: Scott Chacon Date: Fri May 22 18:22:37 2009 -0700 Third commit commit ab1afef80fac8e34258ff41fc1b867c702daa24b Reflog: HEAD@ (Scott Chacon ) Reflog message: updating HEAD Author: Scott Chacon Date: Fri May 22 18:15:24 2009 -0700 Modify repo.rb a bit
Похоже, что последний коммит — это и есть тот, который мы потеряли; его можно восстановить, создав новую ветку, указывающую на него. Например, создадим новую ветку с именем recover-branch , указывающую на этот коммит ( ab1afef ):
$ git branch recover-branch ab1afef $ git log --pretty=oneline recover-branch ab1afef80fac8e34258ff41fc1b867c702daa24b Modify repo.rb a bit 484a59275031909e19aadb7c92262719cfcdf19a Create repo.rb 1a410efbd13591db07496601ebc7a059dd55cfe9 Third commit cac0cab538b970a37ea1e769cbbde608743bc96d Second commit fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit
Отлично — теперь у нас есть ветка recover-branch , указывающая туда, куда ранее указывала ветка master , тем самым делая потерянные коммиты вновь доступными. Теперь предположим, что потерянные изменения отсутствуют в reflog — для симуляции такого состояния удалим восстановленную ветку и очистим reflog.
$ git branch -D recover-branch $ rm -Rf .git/logs/
В этом случае два первых коммита недоступны ниоткуда. Так как данные reflog хранятся в каталоге .git/logs/ , которую мы только что удалили, то теперь у нас нет reflog. Как теперь восстановить коммиты? Один из вариантов — использование утилиты git fsck , проверяющую внутреннюю базу данных на целостность. Если выполнить её с ключом —full , будут показаны все объекты, недостижимые из других объектов:
$ git fsck --full Checking object directories: 100% (256/256), done. Checking objects: 100% (18/18), done. dangling blob d670460b4b4aece5915caf5c68d12f560a9fe3e4 dangling commit ab1afef80fac8e34258ff41fc1b867c702daa24b dangling tree aea790b9a58f6cf6f2804eeac9f0abbe9631e4c9 dangling blob 7108f7ecb345ee9d0084193f147cdad4d2998293
В нашем случае потерянный коммит указан после слов «dangling commit» («висячий коммит»). Его можно восстановить аналогичным образом, создав новую ветку, указывающую на этот SHA-1.
Удаление объектов
Git — замечательный инструмент с кучей классных возможностей, но некоторые из них способны стать источником проблем; например, команда git clone загружает проект вместе со всей историей, включая все версии всех файлов. Это нормально, если в репозитории хранится только исходный код, так как Git хорошо оптимизирован под такой тип данных и может эффективно сжимать их. Однако, если когда-либо в проект был добавлен большой файл, каждый, кто потом захочет клонировать проект, будет вынужден скачивать этот файл, даже если он был удалён в следующем коммите. Он будет в базе всегда, просто потому, что он доступен в истории.
Это может стать большой проблемой при конвертации Subversion или Perforce репозиториев в Git. В этих системах вам не нужно загружать всю историю, поэтому добавление больших файлов не имеет там особых последствий. Если при импорте из другой системы или при каких-либо других обстоятельствах стало ясно, что ваш репозиторий намного больше, чем он должен быть, то как раз сейчас мы расскажем, как можно найти и удалить большие объекты.
Предупреждаем: дальнейшие действия переписывают историю изменений. Каждый коммит, начиная с самого раннего, из которого нужно удалить большой файл, будет переписан. Если сделать это непосредственно после импорта, пока никто ещё не работал с репозиторием, то всё окей, иначе придётся сообщить всем участникам о необходимости перебазирования их правок относительно ваших новых коммитов.
Для примера добавим большой файл в тестовый репозиторий, удалим его в следующем коммите, а потом найдём и удалим его полностью из базы. Сначала добавим большой файл в нашу историю:
$ curl https://www.kernel.org/pub/software/scm/git/git-2.1.0.tar.gz > git.tgz $ git add git.tgz $ git commit -m 'Add git tarball' [master 7b30847] Add git tarball 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 git.tgz
Упс, мы нечаянно. Нам лучше избавиться от этого файла:
$ git rm git.tgz rm 'git.tgz' $ git commit -m 'Oops - remove large tarball' [master dadf725] Oops - remove large tarball 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 git.tgz
Теперь запустим сборщик мусора и посмотрим, сколько места сейчас используется:
$ git gc Counting objects: 17, done. Delta compression using up to 8 threads. Compressing objects: 100% (13/13), done. Writing objects: 100% (17/17), done. Total 17 (delta 1), reused 10 (delta 0)
Чтобы быстро узнать, сколько места занято, можно воспользоваться командой count-objects :
$ git count-objects -v count: 7 size: 32 in-pack: 17 packs: 1 size-pack: 4868 prune-packable: 0 garbage: 0 size-garbage: 0
Строка size-pack — это размер pack-файлов в килобайтах, то есть всего занято почти 5 MБ. Перед последним коммитом использовалось около 2 КБ — очевидно, удаление файла не удалило его из истории. Всякий раз, когда кто-либо захочет клонировать этот репозиторий, ему придётся скачивать все 5 МБ для того, чтобы заполучить этот крошечный проект, просто потому, что однажды вы имели неосторожность добавить большой файл. Давайте же исправим это!
Для начала найдём проблемный файл. В данном случае, мы уже знаем, что это за файл. Но если бы не знали, как можно было бы определить, какие файлы занимают много места? При вызове git gc все объекты упаковываются в один pack-файл, но, несмотря на это, определить самые крупные файлы можно, запустив служебную команду git verify-pack и отсортировав её вывод по третьей колонке, в которой записан размер файла. Так как нас интересуют самые крупный файлы, оставим три последние строки с помощью tail :
$ git verify-pack -v .git/objects/pack/pack-29…69.idx \ | sort -k 3 -n \ | tail -3 dadf7258d699da2c8d89b09ef6670edb7d5f91b4 commit 229 159 12 033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5 blob 22044 5792 4977696 82c99a3e86bb1267b236a4b6eff7868d97489af1 blob 4975916 4976258 1438
Большой объект внизу списка, его размер — 5 МБ. Для того чтобы узнать, что это за файл, воспользуемся командой rev-list , которая уже упоминалась в разделе Проверка формата сообщения коммита главы 8. Если передать ей ключ —objects , она выдаст хеши всех коммитов, а также хеши объектов и соответствующие им имена файлов. Воспользуемся этим для определения имени выбранного объекта:
$ git rev-list --objects --all | grep 82c99a3 82c99a3e86bb1267b236a4b6eff7868d97489af1 git.tgz
Теперь необходимо удалить данный файл из всех деревьев в прошлом. Легко получить все коммиты, которые изменяли данный файл:
$ git log --oneline --branches -- git.tgz dadf725 Oops - remove large tarball 7b30847 Add git tarball
Для полного удаления этого файла из истории необходимо переписать все коммиты, начиная с 7b30847 . Воспользуемся командой filter-branch , о которой мы писали в разделе Перезапись истории главы 7:
$ git filter-branch --index-filter \ 'git rm --ignore-unmatch --cached git.tgz' -- 7b30847^.. Rewrite 7b30847d080183a1ab7d18fb202473b3096e9f34 (1/2)rm 'git.tgz' Rewrite dadf7258d699da2c8d89b09ef6670edb7d5f91b4 (2/2) Ref 'refs/heads/master' was rewritten
Опция —index-filter похожа на —tree-filter , использовавшуюся в разделе Перезапись истории главы 7, за исключением того, что вместо передачи команды, модифицирующей файлы на диске, мы используем команду, изменяющую файлы в индексе.
Вместо удаления файла чем-то вроде rm file , мы используем git rm —cached , так как нам надо удалить файл из индекса, а не с диска. Причина, по которой мы делаем именно так — скорость: нет необходимости извлекать каждую ревизию на диск, чтобы применить фильтр, а это может очень сильно ускорить процесс. Если хотите, можете использовать и tree-filter для получения аналогичного результата. Опция —ignore-unmatch команды git rm отключает вывод сообщения об ошибке в случае отсутствия файлов, соответствующих шаблону. Ещё один момент: мы указали команде filter-branch переписывать историю, начиная с коммита 7b30847 , потому что мы знаем, что именно в нём впервые появилась проблема. По умолчанию перезапись начинается с самого первого коммита, что потребовало бы гораздо больше времени.
Теперь история не содержит ссылок на данный файл. Однако, в reflog и в новом наборе ссылок, добавленном Git в .git/refs/original после выполнения filter-branch , ссылки на него всё ещё присутствуют, поэтому необходимо их удалить, а затем переупаковать базу. Необходимо избавиться от всех возможных ссылок на старые коммиты перед переупаковкой:
$ rm -Rf .git/refs/original $ rm -Rf .git/logs/ $ git gc Counting objects: 15, done. Delta compression using up to 8 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (15/15), done. Total 15 (delta 1), reused 12 (delta 0)
Проверим, сколько места удалось освободить:
$ git count-objects -v count: 11 size: 4904 in-pack: 15 packs: 1 size-pack: 8 prune-packable: 0 garbage: 0 size-garbage: 0
Размер упакованного репозитория сократился до 8 КБ, что намного лучше, чем 5 МБ. Из значения поля size видно, что большой объект всё ещё хранится в одном из ваших «рыхлых» объектов, но, что самое главное, при любой последующей отправке данных наружу (а значит и при последующих клонированиях репозитория) он передаваться не будет. Если очень хочется, можно удалить его навсегда локально, выполнив git prune —expire :
$ git prune --expire now $ git count-objects -v count: 0 size: 0 in-pack: 15 packs: 1 size-pack: 8 prune-packable: 0 garbage: 0 size-garbage: 0
Исчезли настройки источников как восстановить
отображаются рекомендации пинов на основе авторов, на которых вы подписаны, а также ваших досок, тем и истории просмотров.
В настройках главной ленты вы можете выбрать, какой контент вы будете видеть.
В настройках главной ленты можно изменить предпочтения на основе приведенных ниже источников.
Рекомендации автоматически отключаются для архивных и секретных досок. В разделе настроек ленты такие доски помечены значком замка. При желании вы можете в любое время включить рекомендации на их основе.
Включение или отключение рекомендаций не повлияет на объявления, которые вы видите в ленте. Вы можете
, которую Pinterest использует при подборе объявлений для показа вам.
В настройках главной ленты можно изменить предпочтения на основе приведенных ниже источников.
Рекомендации автоматически отключаются для архивных и секретных досок. В разделе настроек ленты такие доски помечены значком замка. При желании вы можете в любое время включить рекомендации на их основе.
Включение или отключение рекомендаций не повлияет на объявления, которые вы видите в ленте. Вы можете
, которую Pinterest использует при подборе объявлений для показа вам.
В настройках главной ленты можно изменить предпочтения на основе приведенных ниже источников.
Рекомендации автоматически отключаются для архивных и секретных досок. В разделе настроек ленты такие доски помечены значком замка. При желании вы можете в любое время включить рекомендации на их основе.
Включение или отключение рекомендаций не повлияет на объявления, которые вы видите в ленте. Вы можете
, которую Pinterest использует при подборе объявлений для показа вам.