Git выводит файл из-под контроля

Обновлено: 21.11.2024

Команды git reset , git checkout и git revert — одни из самых полезных инструментов в вашем наборе инструментов Git. Все они позволяют отменить какое-либо изменение в вашем репозитории, а первые две команды можно использовать для управления либо коммитами, либо отдельными файлами.

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

Каждую команду полезно рассматривать с точки зрения ее влияния на три механизма управления состоянием репозитория Git: рабочий каталог, промежуточный снимок и историю коммитов. Эти компоненты иногда называют «тремя деревьями» Git. Мы подробно изучаем три дерева на странице сброса git. Помните об этих механизмах, когда будете читать эту статью.

Извлечение — это операция, которая перемещает указатель HEAD ref на указанную фиксацию. Чтобы продемонстрировать это, рассмотрим следующий пример.

В этом примере показана последовательность коммитов в основной ветке. Ссылка HEAD и ссылка основной ветки в настоящее время указывают на коммит d. Теперь давайте выполним git checkout b

Это обновление дерева "История фиксаций". Команду git checkout можно использовать в области фиксации или на уровне файла. Проверка на уровне файла изменит содержимое файла на содержимое конкретной фиксации.

Откат — это операция, которая берет указанную фиксацию и создает новую фиксацию, которая инвертирует указанную фиксацию. git revert может выполняться только на уровне фиксации и не имеет функций на уровне файлов.

Сброс — это операция, которая берет указанную фиксацию и сбрасывает «три дерева» в соответствии с состоянием репозитория на момент указанной фиксации. Сброс можно вызвать в трех разных режимах, соответствующих трем деревьям.

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

Справочник Git Reset, Revert и Checkout

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

< td>Уровень файла

Команда	Область	Общие варианты использования
git reset	Уровень фиксации	Отменить коммиты в приватной ветке или удалить незафиксированные изменения
git reset	Удалить файл
git checkout	Уровень фиксации	Переключение между ветки или проверять старые снимки
git checkout	На уровне файлов	Отменить изменения в рабочем каталоге
git revert	Commit-level	Отменить коммит в общедоступной ветке
git revert< /td>	Уровень файла	(Н/Д)

Операции на уровне фиксации

Параметры, которые вы передаете в git reset и git checkout, определяют их область действия. Когда вы не включаете путь к файлу в качестве параметра, они работают со всеми коммитами. Это то, что мы будем исследовать в этом разделе. Обратите внимание, что git revert не имеет аналога на уровне файлов.

Сбросить конкретную фиксацию

На уровне фиксации сброс — это способ переместить кончик ветки на другую фиксацию. Это можно использовать для удаления коммитов из текущей ветки. Например, следующая команда перемещает ветвь исправлений назад на две фиксации.

Два коммита, которые были в конце исправления, теперь висят или потерянные коммиты. Это означает, что они будут удалены в следующий раз, когда Git выполнит сборку мусора. Другими словами, вы говорите, что хотите выбросить эти коммиты. Это можно представить следующим образом:

Это использование git reset — простой способ отменить изменения, которые никому не были переданы. Это ваша команда, когда вы начинаете работать над функцией и ловите себя на мысли: «Вот дерьмо, что я делаю? Я должен просто начать сначала».

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

--soft — промежуточный снимок и рабочий каталог никак не изменяются.
--mixed — промежуточный снимок обновляется в соответствии с указанной фиксацией, но рабочий каталог не затрагивается. Это параметр по умолчанию.
--hard — промежуточный снимок и рабочий каталог обновляются в соответствии с указанной фиксацией.

Эти режимы проще рассматривать как определяющие область действия операции сброса git. Для получения более подробной информации посетите страницу git reset.

Проверить старые коммиты

Команда git checkout используется для обновления состояния репозитория до определенного момента в истории проектов. При передаче с именем ветки он позволяет переключаться между ветвями.

Внутри все, что делает вышеприведенная команда, — это перемещает HEAD в другую ветку и обновляет рабочий каталог, чтобы он соответствовал. Поскольку это может перезаписать локальные изменения, Git заставляет вас зафиксировать или спрятать любые изменения в рабочем каталоге, которые будут потеряны во время операции извлечения. В отличие от git reset , git checkout не перемещает ветки.

Вы также можете проверить произвольные коммиты, передав ссылку коммита вместо ветки. Это делает то же самое, что и проверка ветки: она перемещает ссылку HEAD на указанный коммит. Например, следующая команда извлечет прародителя текущего коммита:

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

Отменить общедоступную фиксацию с помощью Revert

Возврат отменяет фиксацию путем создания новой фиксации. Это безопасный способ отменить изменения, так как он не может перезаписать историю коммитов. Например, следующая команда вычислит изменения, содержащиеся в предпоследней фиксации, создаст новую фиксацию, отменяющую эти изменения, и прикрепит новую фиксацию к существующему проекту.

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

Сравните это с git reset , который действительно изменяет существующую историю коммитов. По этой причине git revert следует использовать для отмены изменений в общедоступной ветке, а git reset следует зарезервировать для отмены изменений в частной ветке.

Вы также можете рассматривать git revert как инструмент для отмены зафиксированных изменений, тогда как git reset HEAD предназначен для отмены незафиксированных изменений.

Как и git checkout , git revert может перезаписать файлы в рабочем каталоге, поэтому вам будет предложено зафиксировать или спрятать изменения, которые будут потеряны во время операции возврата.

Операции на уровне файлов

Команды git reset и git checkout также принимают в качестве параметра необязательный путь к файлу. Это резко меняет их поведение. Вместо того, чтобы работать со снимками целиком, это вынуждает их ограничивать свои операции одним файлом.

Git сбросить определенный файл

При вызове с указанием пути к файлу git reset обновляет поэтапный снимок, чтобы он соответствовал версии указанной фиксации. Например, эта команда извлечет версию foo.py из предпоследнего коммита и подготовит ее для следующего коммита:

Как и в случае с версией git reset на уровне фиксации, она чаще используется с HEAD, а не с произвольной фиксацией. Запуск git reset HEAD foo.py отключит foo.py . Содержащиеся в нем изменения будут по-прежнему присутствовать в рабочем каталоге.

Флаги --soft , --mixed и --hard не влияют на версию git reset на уровне файлов, поскольку промежуточный снимок всегда обновляется, а рабочий каталог никогда не обновляется.

Файл проверки Git

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

Например, следующая команда заставляет foo.py в рабочем каталоге соответствовать файлу из предпоследней фиксации:

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

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

Как и git reset , это обычно используется с HEAD в качестве ссылки на фиксацию. Например, git checkout HEAD foo.py отбрасывает неустановленные изменения в foo.py. Это похоже на git reset HEAD --hard , но работает только с указанным файлом.

Обзор

Теперь у вас должны быть все необходимые инструменты для отмены изменений в репозитории Git. Команды git reset , git checkout и git revert могут сбивать с толку, но когда вы думаете об их влиянии на рабочий каталог, промежуточный снимок и историю коммитов, должно быть легче определить, какая команда подходит для текущей задачи разработки.< /p>

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

Для определения отображаемых файлов можно использовать один или несколько из приведенных ниже параметров:

ВАРИАНТЫ

Показывать кешированные файлы в выводе (по умолчанию)

Показать удаленные файлы в выходных данных

Показать измененные файлы в выходных данных

Показать другие (т.е. неотслеживаемые) файлы в выходных данных

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

Показать в выходных данных биты режима поэтапного содержимого, имя объекта и номер этапа.

Если весь каталог классифицируется как "другое", показывается только его имя (с косой чертой в конце), а не все его содержимое.

Не указывайте пустые каталоги. Без --directory не действует.

Показать неслитые файлы в выводе (принудительно --stage)

Показать файлы в файловой системе, которые необходимо удалить из-за конфликтов между файлами и каталогами для успешного выполнения checkout-index.

\0 завершение строки при выводе и не заключать имена файлов в кавычки. Дополнительную информацию см. в разделе OUTPUT ниже.

Если отображаются только имена файлов, подавите дубликаты, которые могут возникать из-за наличия нескольких этапов во время слияния, или задайте параметры --deleted и --modified одновременно. Если используется любой из параметров -t , --unmerged или --stage , этот параметр не действует.

Пропускать неотслеживаемые файлы, соответствующие шаблону. Обратите внимание, что шаблон является шаблоном подстановочного знака оболочки. Дополнительные сведения см. в разделе ИСКЛЮЧЕНИЕ ШАБЛОНОВ ниже.

Чтение шаблонов исключения из ; 1 на строку.

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

Добавьте стандартные исключения Git: .git/info/exclude, .gitignore в каждый каталог и глобальный файл исключений пользователя.

Если какой-либо из них не отображается в индексе, расценивайте это как ошибку (возвратите 1).

При использовании --error-unmatch для преобразования предоставленных пользователем аргументов (т. е. шаблона пути) в пути, представьте, что пути, которые были удалены в индексе с момента указанного имени, все еще присутствуют. Использование этой опции с опциями -s или -u не имеет смысла.

Эта функция наполовину устарела. Для написания сценариев git-status[1] --porcelain и git-diff-files[1] --name-status почти всегда являются лучшими альтернативами, и пользователям следует обратить внимание на git-status[1] --short или git- diff[1] --name-status для более удобных альтернатив.

Этот параметр определяет статус файла с помощью следующих тегов (за которыми следует пробел) в начале каждой строки:

Аналогично -t , но используйте строчные буквы для файлов, помеченных как предполагать без изменений (см. git-update-index[1]).

Аналогично -t , но используйте строчные буквы для файлов, помеченных как действительные для fsmonitor (см. git-update-index[1]).

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

Рекурсивно вызывает ls-файлы для каждого активного субмодуля в репозитории. В настоящее время поддерживается только режим --cached.

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

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

Показать и файлов. это идентификация содержимого файла, используемая Git, когда атрибут "text" имеет значение "auto" (или не установлен, а core.autocrlf не равен false). либо "-text", "none", "lf", "crlf", "mixed" или "".

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

— это атрибут, который используется при извлечении или фиксации, это либо "", "-text", "text", "text=auto", "text eol=lf", "text eol=crlf". Начиная с Git 2.10 поддерживаются «text=auto eol=lf» и «text=auto eol=crlf».

И в индексе ("i/"), и в рабочем дереве ("w/") отображаются для обычных файлов, за которыми следует ("attr/").

Если индекс разреженный, показывать разреженные каталоги без расширения до содержащихся файлов. Разреженные каталоги будут показаны с косой чертой в конце, например "x/" для разреженного каталога "x".

Больше не интерпретируйте аргументы как опции.

Файлы для отображения. Если файлы не указаны, отображаются все файлы, соответствующие другим указанным критериям.

ВЫВОД

git ls-files просто выводит имена файлов, если не указан параметр --stage, и в этом случае он выводит:

git ls-files --eol покажет i/ w/ attr/

git ls-files --unmerged и git ls-files --stage можно использовать для просмотра подробной информации о неслитых путях.

Для неслитного пути вместо записи одной пары режим/SHA-1 индекс записывает до трех таких пар; один из дерева O на этапе 1, A на этапе 2 и B на этапе 3. Эта информация может использоваться пользователем (или фарфором), чтобы увидеть, что в конечном итоге должно быть записано на пути. (дополнительную информацию о состоянии см. в git-read-tree[1])

Без параметра -z пути с «необычными» символами заключаются в кавычки, как объяснено для переменной конфигурации core.quotePath (см. git-config[1]). При использовании -z имя файла выводится дословно, а строка завершается нулевым байтом.

ИСКЛЮЧИТЬ ШАБЛОНЫ

git ls-files может использовать список «исключающих шаблонов» при обходе дерева каталогов и поиске файлов, которые будут отображаться, когда указаны флаги --others или --ignored. gitignore[5] указывает формат шаблонов исключения.

Эти шаблоны исключений взяты из следующих источников в следующем порядке:

Флаг командной строки --exclude=

задает один шаблон. Шаблоны упорядочены в том же порядке, в котором они появляются в командной строке.

Флаг командной строки --exclude-from= указывает файл, содержащий список шаблонов. Шаблоны упорядочены в том же порядке, что и в файле.

Флаг командной строки --exclude-per-directory= указывает имя файла в каждом каталоге, который проверяет git ls-files, обычно это .gitignore . Файлы в более глубоких каталогах имеют приоритет. Шаблоны упорядочены в том же порядке, что и в файлах.

Шаблон, указанный в командной строке с параметром --exclude или прочитанный из файла, указанного с параметром --exclude-from, относится к вершине дерева каталогов. Шаблон, прочитанный из файла, указанного параметром --exclude-per-directory, относится к каталогу, в котором находится файл шаблона.

Установка и настройка

Получение и создание проектов

Базовый снимок

Ветвление и слияние

Обмен проектами и их обновление

Осмотр и сравнение

Исправление

Отладка

Электронная почта

Внешние системы

Администратор сервера

Руководства

Администрирование

Связные команды

Проверьте свою версию git, запустив

git-rm - Удалить файлы из рабочего дерева и из индекса

ОБЗОР

ОПИСАНИЕ

Удалить файлы, соответствующие пути, из индекса или из рабочего дерева и индекса. git rm не удалит файл только из вашего рабочего каталога. (Нет возможности удалить файл только из рабочего дерева и при этом сохранить его в индексе; используйте /bin/rm, если вы хотите это сделать.) Удаляемые файлы должны быть идентичны вершине ветви, и никакие обновления их содержимого не могут быть размещены в индексе, хотя это поведение по умолчанию можно переопределить с помощью параметра -f. Если задан параметр --cached, подготовленное содержимое должно соответствовать либо концу ветки, либо файлу на диске, что позволяет удалить файл только из индекса. Когда используются разреженные проверки (см. git-sparse-checkout[1]), git rm удалит пути только в шаблонах разреженных проверок.

ВАРИАНТЫ

Файлы для удаления. Начальное имя каталога (например, dir для удаления dir/file1 и dir/file2 ) может быть задано для удаления всех файлов в каталоге и рекурсивно всех подкаталогов, но для этого требуется явный указанный параметр -r.

Команда удаляет только те пути, которые известны Git.

Подстановка файлов соответствует границам каталогов. Таким образом, при наличии двух каталогов d и d2 существует разница между использованием git rm 'd*' и git rm 'd/*' , так как первый также удалит весь каталог d2 .

Подробнее см. в записи pathspec в gitglossary[7].

Переопределить проверку актуальности.

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

Разрешить рекурсивное удаление, если задано начальное имя каталога.

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

Используйте этот параметр, чтобы отменить постановку и удалить пути только из индекса. Файлы рабочего дерева, независимо от того, изменены они или нет, останутся нетронутыми.

Выйти с нулевым статусом, даже если не найдено ни одного файла.

Разрешить обновление записей индекса за пределами конуса разреженной проверки. Обычно git rm отказывается обновлять записи индекса, пути которых не соответствуют конусу разреженной проверки. См. git-sparse-checkout[1] для получения дополнительной информации.

git rm обычно выводит одну строку (в виде команды rm) для каждого удаленного файла. Этот параметр подавляет этот вывод.

Pathspec передается вместо аргументов командной строки. Если точно - то используется стандартный ввод. Элементы Pathspec разделяются символами LF или CR/LF. Элементы Pathspec можно заключать в кавычки, как описано для переменной конфигурации core.quotePath (см. git-config[1]). См. также --pathspec-file-nul и global --literal-pathspecs .

Имеет смысл только с параметром --pathspec-from-file . Элементы Pathspec разделяются символом NUL, а все остальные символы воспринимаются буквально (включая символы новой строки и кавычки).

УДАЛЕНИЕ ФАЙЛОВ, ИСЧЕЗНУВШИХ ИЗ ФАЙЛОВОЙ СИСТЕМЫ

У git rm нет возможности удалить из индекса только те пути, которые исчезли из файловой системы. Однако, в зависимости от варианта использования, есть несколько способов сделать это.

Использование «git commit -a»

Если вы предполагаете, что ваша следующая фиксация должна записывать все изменения отслеживаемых файлов в рабочем дереве и записывать все удаления файлов, которые были удалены из рабочего дерева с помощью rm (в отличие от git rm ), используйте git commit -a , так как он автоматически заметит и запишет все удаления. Вы также можете получить аналогичный эффект без фиксации, используя git add -u .

Использование «git add -A»

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

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

а затем распакуйте новый код в рабочем дереве. В качестве альтернативы вы можете rsync внести изменения в рабочее дерево.

После этого проще всего записать все удаления, добавления и изменения в рабочем дереве:

Другие способы

Если все, что вы действительно хотите сделать, это удалить из индекса файлы, которых больше нет в рабочем дереве (возможно, из-за того, что ваше рабочее дерево грязное и вы не можете использовать git commit -a ), используйте следующую команду :

ПОДМОДУЛИ

Только подмодули, использующие git-файл (что означает, что они были клонированы с помощью Git версии 1.7.8 или новее), будут удалены из рабочего дерева, поскольку их репозиторий находится внутри каталога .git суперпроекта. Если подмодуль (или один из вложенных в него) по-прежнему использует каталог .git, git rm переместит каталог git подмодулей в каталог git суперпроектов, чтобы защитить историю подмодуля. Если он существует, то подмодуль. раздел в файле gitmodules[5] также будет удален, а этот файл будет помещен в промежуточное состояние (если только не используются --cached или -n).

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

Если вы хотите удалить только локальное извлечение подмодуля из вашего рабочего дерева без фиксации удаления, используйте вместо этого git-submodule[1] deinit. Также см. gitsubmodules[7] для получения подробной информации об удалении подмодуля.

ПРИМЕРЫ

Удаляет из индекса все файлы *.txt, находящиеся в каталоге Documentation и любых его подкаталогах.

Обратите внимание, что в этом примере звездочка * взята из оболочки; это позволяет Git, а не оболочке, расширять пути к файлам и подкаталогам в каталоге Documentation/.

Каждый разработчик хотя бы раз удалял неправильный файл из своего проекта. Это может быть как наспех выполненная команда `rm -rf`, так и рассеянный выбор и удаление, а может результат ошибочного скрипта. Какой бы ни была причина, удаление важного файла может быть проблематичным, если его не устранить немедленно. При работе в команде случайное удаление файла, а затем отправка его вверх по течению может иметь катастрофические последствия для других членов команды, которые получают изменения. В зависимости от файла они либо сразу получат сообщение об ошибке, либо, в худшем случае, ошибка появится где-то в конце строки — может быть, в каком-то не столь очевидном месте — и в этот момент может быть трудно выяснить точную причину.

Итак, теперь, когда вы случайно удалили файл или файлы, как их восстановить? Поскольку Git — это система контроля версий, в ней есть функции для отката одного файла до предыдущей версии, включая удаленные файлы.

В этом руководстве мы рассмотрим три способа восстановления удаленного файла: с помощью командной строки Git, с помощью веб-интерфейса и пользовательского интерфейса приложения GitHub и с помощью полномасштабного решения для резервного копирования с помощью BackHub.

Вы можете следовать этому руководству, клонировав демонстрационный репозиторий.

Восстановление удаленных файлов с помощью командной строки

Для восстановления удаленного файла с помощью командной строки Git используется команда ` git restore ` или ` git checkout `. Всякий раз, когда вы изменяете файлы в Git, включая создание новых файлов, редактирование или удаление существующих файлов, изменения начинаются как неустановленные. Затем вы вносите изменения с помощью команды ` git add` и, наконец, вы фиксируете изменения с помощью команды ` git commit `. Git предоставляет способы восстановить удаленный файл в любой момент этого жизненного цикла изменений.

Если вы еще не подготовили удаление, просто запустите `git restore`, и файл будет восстановлен из индекса.

Однако, если вы поместили изменения, запуск ` git restore` вызовет ошибку, так как файл больше не существует в индексе.

В этом случае вам нужно запустить `git restore --staged --worktree`. Аргумент `--staged` указывает `git` восстановить файл в индексе из HEAD, а аргумент `--worktree` сообщает git также восстановить рабочее дерево.

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

В демонстрационном репозитории файл `file1.txt` уже удален и зафиксирован. Давайте восстановим этот файл. Чтобы выяснить, какой коммит удалил `file1.txt`, вам нужно использовать команду `git rev-list`:

git rev-list HEAD -n 1 -- file1.txt

Эта команда указывает `git` вывести список всех коммитов, которые могут быть получены из HEAD, которые изменили файл `file1.txt`. Опция `-n 1` указывает `git` ограничить результат только одной фиксацией. Результатом является контрольная сумма фиксации, которая удалила файл. Вы можете проверить, что это ошибочный коммит, используя команду ` git show ` с контрольной суммой -

Коммит перед этим является последним коммитом, в котором присутствовал этот файл. Вы можете восстановить файл из этой конкретной фиксации, выполнив следующую команду. `^` в конце хэша коммита указывает Git, что нужно получить коммит перед этим:

git checkout 3d5210ddd8632d539ed3f5e362dc047ed508a510^ file1.txt

Плюсы и минусы использования командной строки

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

Использование настольного приложения GitHub

Если вам удобнее работать с графическим интерфейсом, вы можете использовать рабочий стол GitHub, доступный для macOS и Windows. Как и в предыдущем случае, есть два сценария: один, когда вы не зафиксировали удаление, и другой, когда вы сделали это.

Все изменения, которые вы вносите в свой репозиторий, будут отображаться в тестовой области на левой боковой панели приложения. Там вы можете отменить изменения, которые работают аналогично команде `git restore`. Если вы еще не зафиксировали удаление, вы можете использовать эту функцию для быстрого восстановления удаленного файла.

Удалите `file5.txt` из репозитория и вернитесь на GitHub Desktop. Вы должны увидеть удаление в тестовой области.

Вы можете щелкнуть правой кнопкой мыши изменение и выбрать Отменить изменения .

Вас попросят подтвердить. После подтверждения изменение будет отменено, а удаленный файл вернется на свое место.

Если вы уже зафиксировали изменение, вам необходимо знать хеш коммита неправильного коммита. Это невозможно сделать из настольного приложения GitHub, поэтому вам нужно использовать командную строку и запустить команду `git rev-list`, которую мы обсуждали ранее.

Как и раньше, давайте восстановим уже удаленный файл `file1.txt`. Во-первых, вам нужно знать хэш фиксации, которая удалила файл:

$ git rev-list HEAD -n 1 -- file1.txt

В приложении для коммитов указаны их имена, а не хэши. Чтобы узнать имя коммита, вам нужно запустить команду `git show` с хешем коммита:

git-шоу 3d5210ddd8632d539ed3f5e362dc047ed508a510

Название фиксации — «Добавить файл4». Затем найдите эту фиксацию на вкладке «История» в приложении.

Щелкните правой кнопкой мыши фиксацию и выберите Отменить изменения в фиксации .

Это отменит ошибочную фиксацию и создаст новую фиксацию.

Плюсы и минусы использования настольного приложения GitHub

Этот метод сравнительно проще, чем использование командной строки, и лучше, если вы знакомы с графическими интерфейсами. Однако у него есть следующие недостатки:

Настольное приложение доступно только для Windows и macOS. Если вы используете Linux, вы не сможете использовать этот метод.
Если вы уже зафиксировали удаление, этот метод становится громоздким, поскольку вам нужно использовать командную строку, чтобы найти имя фиксации, а затем выполнить поиск по истории в приложении, чтобы найти фиксацию.
С помощью этого метода невозможно извлечь из фиксации только требуемый файл. Вам нужно отменить всю фиксацию, а это означает, что любые другие изменения, сделанные фиксацией, также будут отменены.

Использование веб-интерфейса GitHub

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

Давайте восстановим уже удаленный `file1.txt` в репозитории. Как и в предыдущем подходе, вам нужно знать, какая фиксация удалила файл, используя описанную ранее команду `git rev-list`. В нашем случае хэш коммита — `3d5210ddd8632d539ed3f5e362dc047ed508a510`.

Нажмите «Обзор файлов», и вам будет представлена структура проекта для этой конкретной фиксации.

Найдите файл, который хотите восстановить. В данном случае `file1.txt`. Откройте его, нажав на него.

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

git добавить файл1.txt

git commit -m "Повторно ввести файл1.txt"

Плюсы и минусы использования веб-интерфейса GitHub

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

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

Использование полной резервной копии

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

BackHub предлагает мощные функции, такие как ночные снимки, синхронизация с Amazon S3, резервное копирование метаданных репозитория (ошибки, запросы на вытягивание, вики и т. д.), а также возможность клонировать любой снимок непосредственно с сервера BackHub. Использование их решения для полного резервного копирования гарантирует, что вам не придется возиться с Git, когда вы случайно удалите один или несколько файлов. Вместо этого вы можете просто восстановиться из ночной резервной копии. Более того, вы можете восстановить удаленный репозиторий всего за несколько кликов, если случайно удалили его.

Давайте изучим процесс установки BackHub и восстановления файлов из резервной копии.

Установка BackHub

Планы BackHub начинаются от 12 долларов США в месяц. Вы можете подписаться на бесплатную пробную версию со страницы установки. После регистрации вы будете перенаправлены на экран установки, который устанавливает разрешения для вашей учетной записи GitHub. Здесь вы можете выбрать, для каких репозиториев вы хотите создавать резервные копии с помощью BackHub. Вы можете выбрать «Все репозитории», чтобы создать резервную копию всех ваших проектов, или выбрать по отдельности столько, сколько хотите. Если вы выберете «Все репозитории», для любого нового репозитория, который вы создадите на GitHub, будет автоматически создана резервная копия.

Оттуда вам нужно войти в GitHub и авторизовать BackHub для завершения установки. Когда вы вернетесь на панель управления BackHub, вы должны увидеть список резервных копий репозиториев.

С этого момента BackHub будет создавать резервные копии репозиториев каждую ночь. Снимки хранятся в течение тридцати дней, но для корпоративных планов доступно до 1 года (365 дней) хранения. Вы также можете подключить корзину S3 в настройках, если хотите сохранять снимки на неопределенный срок.

Восстановление полной резервной копии

Давайте рассмотрим шаги по восстановлению удаленного файла с помощью BackHub.

Во-первых, давайте удалим файл и отправим его.

git commit -am "Удалить файл5.txt"

Главная страница git push

На панели управления BackHub выберите репозиторий, который вы хотите восстановить.

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

Выбрав снимок, нажмите кнопку «Загрузить файлы». Загрузка будет содержать ZIP со всеми файлами из шапки основной ветки. Оттуда вы можете легко скопировать удаленный файл `file5.txt` в свой локальный репозиторий и приветствовать его фиксацией:

git добавить файл5.txt

git commit -m "Повторно ввести файл5.txt"

Заключение

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

Однако, имея готовое решение для полного резервного копирования, вы можете быть уверены, что сможете справиться с любыми проблемами, которые могут возникнуть из-за удаленных файлов. Вы также сможете без проблем восстановить удаленные файлы. Наличие решения для полного резервного копирования может оказаться полезным в долгосрочной перспективе, особенно в критически важном бизнес-программном обеспечении или командной среде.Обратитесь к BackHub за одним из лучших комплексных решений для резервного копирования и восстановления. Убедитесь сами в действии: начните бесплатную пробную версию BackHub.

Читать дальше

Восстановление удаленного репозитория GitHub

Если вы такой же энтузиаст организации, как и я, вы быстро нажмете кнопку удаления на старом .

Как удалить репозиторий GitHub

Ваша учетная запись GitHub — отличная демонстрация ваших навыков и опыта в качестве разработчика. Может.

Как восстановить удаленную ветку или зафиксировать с помощью Git Reflog

Управление ветвями или фиксациями в Git может быть довольно громоздким. Проблемы варьируются от конфликтов слияния до .

Читайте также: