Как зафиксировать удаление файла

Обновлено: 21.11.2024

Бывают ситуации, когда вы удалили файл в проекте, а теперь хотите его вернуть. Здесь мы предлагаем решение этой проблемы. Выполните следующие шаги и решите проблему.

Шаги по поиску и восстановлению удаленного файла

Поиск пути к файлу

Если вы удалили файл и не знаете, по какому пути он находился, то вам следует выполнить следующую команду:

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

Отображение указанной версии файла

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

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

Восстановление файла в рабочую копию

Чтобы восстановить его в рабочей копии с помощью команды git checkout:

Символ вставки (^) указывает версию файла предыдущей фиксации. В момент фиксации файл может быть удален, поэтому вам нужно просмотреть предыдущую фиксацию, чтобы получить содержимое удаленных файлов.

Команда git log

Команда git log показывает зафиксированные моментальные снимки, используемые для просмотра и фильтрации истории проекта и поиска определенных изменений. Это инструмент, используемый для изучения истории репозитория и поиска конкретной версии проекта. Параметр --all показывает все коммиты в истории веток, тегов и других ссылок. Параметр --full-history упрощает историю, объясняющую конечное состояние дерева.

Команда git checkout

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

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

Давайте рассмотрим несколько способов восстановления удаленного файла в зависимости от того, насколько вы были уверены в том, что действительно хотите удалить файл!

Я удалил файл, но не зафиксировал

Значит, вы удалили файл и сразу поняли, что это ошибка? Это легко, просто сделайте:

Это будет работать независимо от того, было ли удаление поэтапным или нет.

Я удалил файл и зафиксировал удаление

Вы сделали фиксацию, удалив файл, но потом поняли, что хотите сохранить этот файл? Выполните сброс, чтобы вернуться к состоянию перед фиксацией (будьте осторожны: опция «--hard» означает, что команда отменит изменения в отслеживаемых файлах после указанной фиксации — вы также можете не указывать эту опцию, и в этом случае удаление файла будет отображаться как неустановленное изменение вместе с любыми другими изменениями, внесенными вами в ваше рабочее дерево. Затем файл можно будет восстановить, как и в предыдущем сценарии):

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

Я зафиксировал удаление, а затем сделал еще несколько коммитов

Если вы удалили файл, совершили коммит, затем продолжили работу и сделали больше коммитов только для того, чтобы обнаружить, что удаление файла было ошибкой, Git все равно поможет вам! Чтобы найти правильный коммит, сначала проверьте историю удаленного файла:

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

Во втором случае извлеките файл из одной фиксации до этого:

Я удалил файл, зафиксировал и отправил

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

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

Восстановление удаленных файлов в Tower

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

Подробнее

Познакомьтесь с главой «Отмена действий» в нашей бесплатной онлайн-книге.
Часто задаваемые вопросы о Git и управлении версиями
Подробнее об устранении ошибок с помощью CMD+Z в Tower 4 читайте в нашем блоге.

Получите нашу популярную памятку по Git бесплатно!

Самые важные команды вы найдете на лицевой стороне, а полезные советы — на обратной. Более 100 000 разработчиков скачали его, чтобы сделать Git немного проще.

О нас

Как создатели Tower, лучшего клиента Git для Mac и Windows, мы помогаем более чем 100 000 пользователей в таких компаниях, как Apple, Google, Amazon, Twitter и Ebay, получить максимальную отдачу от Git.

Как и в случае с Tower, наша миссия с этой платформой – помочь людям стать лучшими профессионалами.

Вот почему мы бесплатно предоставляем наши руководства, видеоролики и памятки (об управлении версиями в Git и многих других темах).

Каждый разработчик хотя бы раз удалял неправильный файл из своего проекта. Это может быть как наспех выполненная команда `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 (теперь часть Rewind).

Аникет Бхаттачария

Аникет учится в магистратуре по математике и увлекается компьютерами и программным обеспечением. Ему нравится изучать различные области, связанные с программированием, и он работает веб-разработчиком, используя Ruby on Rails и Vue.JS.

Вы можете удалить отдельный файл или весь каталог в своем репозитории на GitHub.

Люди с правами на запись могут удалять файлы или каталоги в репозитории.

Об удалении файлов и каталогов

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

Если вы попытаетесь удалить файл или каталог в репозитории, для которого у вас нет прав на запись, мы разветвим проект на вашу учетную запись пользователя и поможем вам отправить запрос на извлечение в исходный репозиторий после того, как вы зафиксируете свой изменять. Дополнительные сведения см. в разделе «О запросах на вытягивание».

Если файл или каталог, которые вы удалили, содержат конфиденциальные данные, эти данные по-прежнему будут доступны в истории Git репозитория. Чтобы полностью удалить файл с GitHub, вы должны удалить файл из истории вашего репозитория. Дополнительные сведения см. в разделе «Удаление конфиденциальных данных из репозитория».

Удаление файла

Перейдите к файлу в вашем репозитории, который вы хотите удалить.

В верхней части файла нажмите

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

Если с вашей учетной записью на GitHub.com связано несколько адресов электронной почты, щелкните раскрывающееся меню адресов электронной почты и выберите адрес электронной почты, который будет использоваться в качестве адреса электронной почты автора Git. В этом раскрывающемся меню отображаются только подтвержденные адреса электронной почты. Если вы включили конфиденциальность адреса электронной почты, то @users.noreply.github.com является адресом электронной почты автора коммита по умолчанию. Дополнительные сведения см. в разделе «Настройка адреса электронной почты для фиксации».

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

Нажмите «Предложить изменение файла».

Удаление каталога

Перейдите к каталогу в вашем репозитории, который вы хотите удалить.

В правом верхнем углу нажмите

, затем нажмите «Удалить каталог».

Просмотрите файлы, которые вы удалите.

Нажмите «Предложить изменение файла».

Если вы фиксируете конфиденциальные данные, такие как пароль или ключ SSH, в репозиторий Git, вы можете удалить их из истории. Чтобы полностью удалить ненужные файлы из истории репозитория, вы можете использовать инструмент git filter-repo или инструмент с открытым исходным кодом BFG Repo-Cleaner.

Инструмент git filter-repo и BFG Repo-Cleaner переписывают историю вашего репозитория, что изменяет SHA для существующих коммитов, которые вы изменяете, и любых зависимых коммитов. Измененные SHA фиксации могут повлиять на открытые запросы на вытягивание в вашем репозитории. Мы рекомендуем объединять или закрывать все открытые пулл-реквесты перед удалением файлов из репозитория.

Вы можете удалить файл из последней фиксации с помощью git rm . Информацию об удалении файла, добавленного с последней фиксацией, см. в разделе «О больших файлах на GitHub».

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

Очистка файла из истории репозитория

Вы можете удалить файл из истории репозитория с помощью инструмента git filter-repo или инструмента с открытым исходным кодом BFG Repo-Cleaner.

BFG Repo-Cleaner – это инструмент, созданный и поддерживаемый сообществом открытого исходного кода. Это более быстрая и простая альтернатива git filter-branch для удаления нежелательных данных.

Например, чтобы удалить файл с конфиденциальными данными и оставить нетронутым последний коммит, выполните:

Чтобы заменить весь текст, указанный в файле passwords.txt, везде, где он встречается в истории вашего репозитория, выполните:

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

Полные инструкции по использованию и загрузке см. в документации BFG Repo-Cleaner.

Использование git filter-repo

Предупреждение. Если вы запустите git filter-repo после сохранения изменений, вы не сможете получить свои изменения с помощью других команд хранения. Перед запуском git filter-repo мы рекомендуем удалить все сделанные вами изменения. Чтобы удалить последний набор изменений, которые вы спрятали, запустите git stash show -p | git применить -R . Дополнительные сведения см. в разделе Инструменты Git — хранение и очистка.

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

Установите последнюю версию инструмента git filter-repo. Вы можете установить git-filter-repo вручную или с помощью менеджера пакетов. Например, чтобы установить инструмент вместе с HomeBrew, используйте команду brew install.

Для получения дополнительной информации см. INSTALL.md в репозитории newren/git-filter-repo.

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

Перейдите в рабочий каталог репозитория.

Выполните следующую команду, заменив PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA на путь к файлу, который вы хотите удалить, а не только на его имя. Эти аргументы будут:

Заставить Git обрабатывать, но не извлекать всю историю каждой ветки и тега
Удалить указанный файл, а также любые пустые коммиты, сгенерированные в результате.
Удалите некоторые конфигурации, такие как удаленный URL, сохраненный в файле .git/config. Вы можете заранее создать резервную копию этого файла для последующего восстановления.
Перезаписать существующие теги

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

Добавьте файл с конфиденциальными данными в .gitignore, чтобы случайно не зафиксировать его снова.

Перепроверьте, что вы удалили все, что хотели, из истории вашего репозитория, и что все ваши ветки извлечены.

Чтобы удалить конфиденциальный файл из выпусков с тегами, вам также потребуется принудительно отправить теги Git:

Полное удаление данных с GitHub

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

Обратитесь в службу поддержки GitHub и попросите их удалить кешированные представления и ссылки на конфиденциальные данные в запросах на вытягивание на GitHub. Укажите название репозитория и/или ссылку на фиксацию, которую нужно удалить.

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

По прошествии некоторого времени, когда вы уверены, что инструмент BFG / git filter-repo не имеет непреднамеренных побочных эффектов, вы можете принудительно разыменовать все объекты в вашем локальном репозитории и собрать мусор с помощью следующих команд (используя Git 1.8.5 или новее):

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

Предотвращение случайных коммитов в будущем

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

Используйте визуальную программу, например GitHub Desktop или gitk, для фиксации изменений. Визуальные программы обычно упрощают просмотр того, какие именно файлы будут добавлены, удалены и изменены при каждой фиксации.
Избегайте универсальных команд git add . и git commit -a в командной строке — вместо этого используйте git add filename и git rm filename для отдельных промежуточных файлов.
Используйте git add --interactive для индивидуального просмотра и внесения изменений в каждый файл.
Используйте команду git diff --cached для просмотра изменений, подготовленных для фиксации. Это именно тот diff, который git commit создаст, если вы не используете флаг -a.

Помогите нам сделать эти документы лучше!

Все документы GitHub имеют открытый исходный код. Видите что-то неправильное или непонятное? Отправьте запрос на вытягивание.

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