Как удалить файл из репозитория git

Добавление, удаление и переименование файлов в репозитории

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

**Добавление файлов в git репозиторий**

Добавление файлов в репозиторий – это достаточно простая операция, мало чем отличающаяся от отправки изменений в отслеживаемых файлах в репозиторий. Мы уже не раз выполняли эту операцию в предыдущих уроках, но сделаем это ещё раз. Создадим новый репозиторий, для этого перейдите в каталог, в котором вы хотите его расположить и введите команду git init.

> git init

Создайте в каталоге файл README.md любым удобным для вас способом, мы сделаем это с помощью команды touch.

> touch README.md

Теперь проверим состояние отслеживаемой директории.

> git status On branch master  Initial commit  Untracked files: (use "git add <file>..." to include in what will be committed)  README.md  nothing added to commit but untracked files present (use "git add" to track)

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

> git add README.md

Посмотрим ещё раз на состояние.

> git status On branch master  Initial commit  Changes to be committed: (use "git rm --cached <file>..." to unstage)  new file: README.md

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

> git commit -m "add README.md file" [master (root-commit) 0bb6c94] add README.md file 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.md

Теперь в рабочей директории и в stage нет объектов, информацию об изменении которых необходимо внести в репозиторий.

> git status On branch master nothing to commit, working tree clean

В репозиторий был сделан один коммит.

> git log --oneline 0bb6c94 add README.md file

Удаление файлов из git репозитория и из stage

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

Вначале разберемся со stage. Создадим ещё один файл.

> touch main.c

“Отправим” файл main.c в stage.

> git add main.c

Внесем изменения в README.md.

> echo "# README" > README.md

Информацию об этом также отправим в stage.

> git add README.md

Посмотрим на состояние stage.

> git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage)  modified: README.md new file: main.c

Если нам необходимо убрать из stage, какой-то из этих файлов (main.c или README.md), то для этого можно воспользоваться командой git –rm cashed <filename>, сделаем это для файла main.c.




> git rm --cached main.c rm 'main.c'

Теперь посмотрим на состояние рабочей директории и stage.

> git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage)  modified: README.md  Untracked files: (use "git add <file>..." to include in what will be committed)  main.c

Видно, что изменения в файле README.md готовы для коммита, а вот файл main.c перешел в состояние – неотслеживаемый. Отправим main.c в stage и, после этого, сделаем коммит в репозиторий.

> git add main.c > git commit -m "add main.c and do some changes in README.md" [master 49049bc] add main.c and do some changes in README.md 2 files changed, 1 insertion(+) create mode 100644 main.c

**Удаление файлов из git репозитория**

Удалить файл из репозитория можно двумя способами: первый – удалить его из рабочей директории и уведомить об этом git; второй – воспользоваться средствами git. Начнем с первого способа. Для начала посмотрим, какие файлы у нас хранятся в репозитории.

> git ls-tree master 100644 blob 7e59600739c96546163833214c36459e324bad0a README.md 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 main.c

Удалим файл main.c из рабочей директории.

> rm main.c > ls README.md

Уведомим об этом систему git.

> git rm main.c rm 'main.c'

Вместо команды git rm можно использовать git add, но само слово add в данном случае будет звучать несколько неоднозначно, поэтому лучше использовать rm. На данном этапе еще можно вернуть все назад с помощью команды git checkout — <filename>, в результате, в нашу рабочую директорию будет скопирован файл из репозитория. Создадим коммит, фиксирующий удаление файла.

> git commit -m "remove main.c" [master d4e22ae] remove main.c 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 main.c

Теперь в репозитории остался только один файл README.md.

> git ls-tree master 100644 blob 7e59600739c96546163833214c36459e324bad0a README.md

Второй способ – это сразу использовать команду git rm без предварительного удаления файла из директории. Вновь создадим файл main.c и добавим его в репозиторий.

> touch main.c > git add main.c > git commit -m "add main.c file" [master 6d93049] add main.c file 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 main.c > git ls-tree master 100644 blob 7e59600739c96546163833214c36459e324bad0a README.md 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 main.c

Удалим файл из репозитория.

> git rm main.c rm 'main.c'  > git commit -m "deleted: main.c file" [master ba7d027] deleted: main.c file 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 main.c

Файла main.c больше нет в репозитории.

> git ls-tree master 100644 blob 7e59600739c96546163833214c36459e324bad0a README.md

Его также нет и в рабочем каталоге.

> ls README.md

Удалите файл README.md из репозитория самостоятельно.

**Переименование файлов в git репозитории**

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

Первый способ. Создадим файл test_main_file.c и добавим его в репозиторий.

> touch test_main_file.c  > git add test_main_file.c  > git commit -m "add test_main_file.c" [master 6cf53ac] add test_main_file.c 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 test_main_file.c

Содержимое репозитория после этого будет выглядеть так.

> git ls-tree master 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 test_main_file.c

Переименуем его на test_main.c.

Сделаем это в рабочей директории.

> mv test_main_file.c test_main.c

Теперь отправим изменение в репозиторий.

> git add . > git commit -m "Rename test_main_file.c" [master 79528c4] Rename test_main_file.c 1 file changed, 0 insertions(+), 0 deletions(-) rename test_main_file.c => test_main.c (100%)

В репозитории и в рабочей директории будет находится только файл test_main.c.

> git ls-tree master 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 test_main.c  > ls test_main.c

Второй способ.

В рамках второго способа рассмотрим работу с командой git mv. Переименуем файл test_main.c в main.c. Текущее содержимое репозитория и рабочего каталога.

> git ls-tree master 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 test_main.c > ls test_main.c

Переименуем файл test_main.c на main.c средствами git.

> git mv test_main.c main.c  > git commit -m "Rename test_main.c file" [master c566f0e] Rename test_main.c file 1 file changed, 0 insertions(+), 0 deletions(-) rename test_main.c => main.c (100%)

Имя файла изменилось как в репозитории так и в рабочем каталоге.

> git ls-tree master 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 main.c  > ls main.c

Отличный курс по git делают ребята из GeekBrains, найдите в разделе “Курсы” курс “Git. Быстрый старт”, он бесплатный!

<<<Часть 7. Поговорим о HEAD и tree-ish Часть 9. Как удалить коммит в git?>>>

Как удалить лишние папки и файлы из git репозитория? — Хабр Q&A

Вариант 1 (история изменений, добавлений файлов в папках останется):

Удалить локально, закомитить
Добавить названия папок в .gitignore
git push

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

git obliterate <путь_папки>(https://github.com/tj/git-extras)
git push --force

После этой операции другим участникам, надо будет локально сбросить ветки:

git fetch git checkout master git reset --hard origin/master

Аналог команды git obliterate исключительно средствами Git:

git filter-branch --force --index-filter \ 'git rm --cached --ignore-unmatch -r <путь_папки>' \ --prune-empty --tag-name-filter cat -- --all

Как полностью убрать файлы из .git репозитория?

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

1 шаг. Закоммитить все изменения

Прежде всего, в вашем репозитории не должно быть недобавленных в git изменений. Даже добавление файла в .gitignore должно быть уже закомичено.

2 шаг. Удалить файлы из кэша репозитория

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

Чтобы убрать его из репозитория необходимо выполнить следующую команду:

git rm --cached scripts.js

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

Очистка всего кэша репозитория

Если вы хотите стереть весь кэш репозитория, то можно выполнить эту же команду rm —cached для всего репозитория:

Флаг -r говорит, что rm будет обходить всё дерево каталогов, лежащих внутри текущей директории, путь к которой задан через символ «.». Флаг —cached сообщает, что файлы будут удалены только из кэша .git, сами файлы при этом останутся лежать на жестком диске и никуда не денутся.

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

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

git commit -m 'git cache clear'

Теперь ваш репозиторий чист.

Как убрать из Git-репозитория файлы с конфиденциальной информацией

Файлы проиндексированы, написано сообщение коммита, данные отправлены на сервер… И вдруг хочется повернуть время вспять. В коммит попал файл, которого там быть не должно. Когда такое случается, приходит время обращаться к поисковику.

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

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

Удаление файлов с конфиденциальной информацией из Git-репозитория (изображение большого размера)

Минимизация ущерба

Итак, вы случайно закоммитили файл с конфиденциальной информацией. Назовём этот файл .env. Сразу после того, как это случилось, надо задать себе пару вопросов:

Отправлен ли коммит в удалённый репозиторий?
Является ли удалённый репозиторий общедоступным?

▍Коммит пока не отправлен в удалённый репозиторий

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

git reset HEAD^ --soft

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

Если же вы хотите сохранить коммит и вам нужно просто удалить из него определённые файлы, тогда поступите так:

git rm .env --cached git commit --amend

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

git rebase -i HEAD~{на сколько коммитов нужно вернуться?}

Это позволит исправить неправильный коммит и поможет не потерять изменения, внесённые в проект остальными коммитами.

▍Коммит отправлен в удалённый репозиторий

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

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

Если вы отправили в репозиторий, после проблемного коммита, и другие коммиты, это не помешает вам убрать файлы с конфиденциальными данными из истории Git, воспользовавшись командой git filter-branch или инструментом BFG Repo-Cleaner.

Вот пример использования git filter-branch:

git filter-branch --force --index-filter "git rm --cached --ignore-unmatch .env" --prune-empty --tag-name-filter cat -- --all

Но, делая это, учитывайте два важных аспекта подобных изменений, вносимых в репозиторий:

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

Нужно ли создавать новые секретные ключи в том случае, если их актуальные версии попали в публичный репозиторий?

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

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

Деактивируйте все ключи или пароли. Это надо сделать в первую очередь. После того, как вы деактивируете ключи, конфиденциальные сведения, ушедшие в общий доступ, оказываются бесполезными.
Настройте файл .gitignore. Сделайте в .gitignore записи о файлах с конфиденциальной информацией для того чтобы Git не отслеживал бы состояние этих файлов.
Подготовьте коммит, в котором нет файлов с конфиденциальной информацией.
Отправьте изменения в репозиторий, снабдите коммит пояснениями о возникшей ситуации. Не пытайтесь скрыть ошибку. Все программисты, работающие над проектом, включая вас, по достоинству оценят наличие в репозитории коммита с разъяснениями ситуации и с описанием того, что именно было исправлено с помощью данного коммита.

Итоги

Надеюсь, мой материал поможет вам в безопасной работе с конфиденциальными данными.

А вам случалось отправлять в общедоступный репозиторий что-то такое, что туда попадать не должно?

Удаление файлов из репозитория Git? — Хабр Q&A

Имеется следующая проблема. Гуглёж особо ни к чему ни привел.

Есть develop и production репозитории git, а между ними bare репозиторий. Рабочая копия приложения содержит гораздо больше файлов, чем нужно хранить в репозитории. При этом в репозитории заведомо присутствуют лишние для него файлы, которые в процессе работы нужно находить и удалять из репозитория (но не из рабочей копии). Казалось бы, нужно использовать git rm --cached для удаления файлов из под контроля, добавление их в gitignore и все.
Если на dev репозитории выполнить git rm --cached, то файлы действительно удалятся из индекса, при этом останутся в локальной рабочей копии. Однако после отправки их в bare репозиторий и при последующем pull на production (или любом другом репозитории) эти файлы, если они присутствовали, будут удалены как из репозитория, так и из рабочей копии.

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

Git. Удалить файл из репозитория » PacificSky.Ru

Если вы сделали commit и push файла в ветку, но потом поняли, что файл не должен был попасть в репозиторий, то в целом можно подумать, что если добавить файл в .gitignore, то файл перестанет индексироваться и git перестанет отслеживать в нем изменения.
Но это не совсем так. По сути файл будет точно так же отслеживаться.

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

Добавить файл в .gitignore
git rm --cached --ignore-unmatch index.php - Удалить файл index.php из репозитория (Физически файл будет храниться на диске)
git commit -am "Сообщение коммита" - Создание коммита который будет автоматически индексировать каждый, уже отслеживаемый, на момент коммита файл, позволяя вам обойтись без git add
git push origin [Название ветки] - Push изменений на сервер

git rm - Как удалить файл из репозитория Git?

Переполнение стека

Около
Продукты
Для команд

Переполнение стека Общественные вопросы и ответы
Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
Вакансии Программирование и связанные с ним технические возможности карьерного роста
Талант Нанимайте технических специалистов и создавайте свой бренд работодателя

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

Переполнение стека

Около
Продукты
Для команд

Переполнение стека Общественные вопросы и ответы
Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
Вакансии Программирование и связанные с ним технические возможности карьерного роста
Талант Нанимайте технических специалистов и создавайте свой бренд работодателя

git - удалить файл из репозитория

Переполнение стека

Около
Продукты
Для команд

Переполнение стека Общественные вопросы и ответы
Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами

git - Как удалить файл ТОЛЬКО в удаленном репозитории?

Переполнение стека

Около
Продукты
Для команд

Переполнение стека Общественные вопросы и ответы
Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами

Удаление файлов из истории репозитория

Документы GitHub

Все продукты
GitHub.com

Начиная
- Быстрый старт
  - Настроить Git
  - Создать репо
  - Форк репо
  - Быть социальным
- Изучение GitHub
  - Продукты GitHub
  - Изучение выпусков раннего доступа с предварительным просмотром функций
  - Типы аккаунтов GitHub
  - Часто задаваемые вопросы об изменениях в планах GitHub
  - Интерфейс командной строки GitHub
  - GitHub Desktop
  - GitHub для мобильных устройств
  - Разрешения на доступ на GitHub
  - Глоссарий GitHub
  - Шпаргалка по Git
  - Учебные ресурсы Git и GitHub
- Регистрация на GitHub
  - Зарегистрируйтесь для новой учетной записи GitHub
  - Подтверждение адреса электронной почты
  - Настройка пробной версии GitHub Enterprise Cloud
  - Настройка пробной версии GitHub Enterprise Server
- Изучение проектов на GitHub
  - Поиск способов внести свой вклад в открытый исходный код на GitHub
  - Сохранение репозиториев со звездочками
  - Следуя за людьми
- Использование GitHub
  - Поддерживаемые браузеры
  - Устранение проблем с подключением
  - Горячие клавиши
Учетные записи пользователей
- Управление настройками учетной записи пользователя
  - О вашей личной панели

Как полностью удалить файл из репозитория Git

Введение

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

Для всех нас: НЕ ПАНИКА! Сделайте глубокий вдох, встаньте из-за стола, пройдитесь несколько минут. Готов? Ладно, приступим!

Цель состоит в том, чтобы полностью стереть файл из репозитория Git, чтобы скрыть все следы вашей ужасной ошибки.Вы хотите быть человеком, который передал ключи AWS в общедоступный репозиторий GitHub, только чтобы через 24 часа узнать, что на майнинг биткойнов было потрачено ~ 2000 долларов США?

Несколько методов

Просто git rm passwords.txt этого не сделает, так как файл будет присутствовать во всех предыдущих коммитах. В зависимости от того, где находится файл, вы можете использовать несколько методов. Здесь представлен обзор каждого сценария в порядке возрастания сложности.

Примечания:

Все эти методы предполагают, что вы знакомы с консольными командами.
Они написаны для Linux, но должны работать в OS X и даже в Windows, если вы используете Git Bash.
Если вы уже внесли изменения, все может усложниться.
Если вы разработчик-одиночка, дерзайте. Но если вы работаете в команде, сначала обсудите это с ними.
Если ваш код (с ненужным файлом) уже открыт (GitHub, BitBucket ,...) тогда вам может не повезти. Но продолжайте читать до конца.

Сценарий 1: файл находится в последней фиксации, а вы еще не отправили

1. Вы хотите сохранить файл локально

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

  git rm --cached $ FILE эхо $ ФАЙЛ >> .gitignore git добавить .gitignore git commit --amend --no-edit git reflog expire --expire = now --all && git gc --prune = now --aggressive

Команды git reflog expire и git gc вызывают сборку мусора, чтобы файл не зависал где-нибудь в вашем репозитории.

2. Вы не хотите хранить файл локально

Просто измените последний коммит.

  git rm $ ФАЙЛ git commit --amend --no-edit git reflog expire --expire = now --all && git gc --prune = now --aggressive

Сценарий 2: файл находится дальше в истории, и вы еще не нажали

Решение 1: BFG Repo-Cleaner

Загрузите 'BFG Repo-Cleaner' здесь. Этот инструмент утверждает, что работает в 10-720 раз быстрее, чем любой другой метод, но вы не можете указать подкаталог, он удалит все файлы с тем же именем в любом каталоге.

Обычно BFG Repo-Cleaner защищает ваш последний коммит, но если вы знаете, что делаете (и знаете, верно?), Вы даете ему опцию --no-blob-protection , что вроде как сказать , делай что хочу и не защищай меня от ошибок.

  java -jar bfg.jar --delete-files $ FILE --no-blob-protection. rm $ FILE git reflog expire --expire = now --all && git gc --prune = now --aggressive

Решение 2. Интерактивная переустановка

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

У этой команды есть подоболочка внутри $ (...) : она находит первую фиксацию, в которую был добавлен файл, даже с учетом переименований файла. Затем команда вне $ (...) запускает интерактивную перебазировку в родительском ( ~ ) этого коммита.

  git rebase --interactive \ $ (git log --follow --find-renames = 40% --diff-filter = A --format =% H - $ FILE) ~

Отредактируйте файл git-rebase-todo : измените первую команду с выбора на редактирование.

  edit 7b0a4be987 Добавить новую таблицу тестов ширины pick 38737174a7 Избегайте использования метода FontProgram # getBaseName, когда он не подходит, обновите документацию pick 66f95dd41b Обобщить чтение байтов для преобразования формата woff # Rebase d1613dff58..66f95dd41b на d1613dff58 (3 команды) # # Команды: # p, pick = использовать фиксацию # r, reword = использовать фиксацию, но отредактировать сообщение фиксации # e, edit = использовать фиксацию, но не вносить поправки # s, squash = использовать фиксацию, но сливается с предыдущей фиксацией # f, fixup = как "squash", но удалить сообщение журнала этой фиксации # x, exec = run команда (остальная часть строки) с использованием оболочки # d, drop = удалить фиксацию # # Эти строки можно переупорядочить; они выполняются сверху вниз.# # Если вы удалите здесь строчку, ЧТО COMMIT БУДЕТ УТЕРЯНЫ. # # Однако, если вы удалите все, перебазирование будет прервано. # # Обратите внимание, что пустые коммиты закомментированы

Затем сохраните и закройте редактор. Перебазирование откатит коммиты до коммита, добавившего нежелательный файл.

  git rm $ ФАЙЛ эхо $ ФАЙЛ >> .gitignore git добавить .gitignore git commit --amend --no-edit git rebase - продолжить git reflog expire --expire = now --all && git gc --prune = now --aggressive

Решение 3. Git filter-branch

Это запускает сценарий, указанный в --tree-filter (f.пример: удалить определенный файл) при каждой фиксации. Это действительно МЕДЛЕННО! Это потому, что он должен проверять каждую фиксацию, запускать сценарий, выполнять фиксацию и переходить к следующей фиксации. Используйте это, когда есть теги или коммиты слияния между ошибочной фиксацией и HEAD, или когда нарушающий файл существует в нескольких ветвях. Другими словами, используйте в крайнем случае!

В этом скрипте я использую тот же трюк, чтобы найти первую фиксацию, которая добавляет ненужный файл, а затем я запускаю фильтр только на родительском этого коммита, вплоть до HEAD текущей ветви. git filer-branch всегда делает резервную копию и ставит перед исходной веткой префикс original . Команда git for-each-ref очищает эти резервные ветки, потому что мы действительно хотим избавиться от этого надоедливого файла. --tag-name-filter cat будет следить за тем, чтобы любые теги перемещались вместе с их коммитами.

  git фильтр-ветка -f \ --prune-empty \ --tag-name-filter cat \ --tree-filter 'rm -f $ FILE' \ $ (git log --follow --find-renames = 40% --diff-filter = A --format =% H - $ FILE) ~..ГОЛОВА git for-each-ref --format = "% (refname)" refs / original / | xargs -n 1 git update-ref -d git reflog expire --expire = now --all && git gc --prune = now --aggressive

Если вы хотите сделать это для всего репозитория (не стоит!):

  git фильтр-ветка -f \ --prune-empty \ --tag-name-filter cat \ --tree-filter 'rm -f $ FILE' \ -- --все git for-each-ref --format = "% (refname)" refs / original / | xargs -n 1 git update-ref -d git reflog expire --expire = now --all && git gc --prune = now --aggressive

Сценарий 3: вы уже отправили

Я не могу повторить это достаточно: сначала проконсультируйтесь с остальной частью вашей команды !!! Если вы этого не сделаете, вы сделаете их жизнь несчастной.
Во-вторых, сделайте резервную копию репозитория, прежде чем делать что-либо еще.
Затем: СДЕЛАЙТЕ РЕЗЕРВНУЮ КОПИЮ !!!
Не знаю, упоминал ли я об этом уже, но действительно ли вы уверены, что сделали резервную копию?
Используйте один из описанных выше методов для удаления файла.
Принудительно нажмите, но знайте, что делаете, и помните о последствиях, потому что нет возможности вернуться, если у вас нет резервной копии. --force-with-lease должно быть здесь по умолчанию, потому что сначала проверяется, что вы не перезаписываете работу других людей. См. Также блог Atlassian для отличного объяснения.
```
  git push --force-with-lease origin $ BRANCH  
```

Сценарий 4: коммиты уже находятся на GitHub

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

Это можно сделать двумя способами:

, если они сделали форк или клон репозитория: принудительное нажатие обновит только наш репозиторий, оно не будет обновлять форки / клоны.
, если им известен точный хэш коммита, добавившего файл (возможно, они его записали или веб-страница все еще находится в кеше браузера), по URL-адресу: https://github.com/$USER/ $ REPO / совершить / $ COMMIT

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

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

В следующем блоге я объясню некоторые передовые методы, используемые в iText Software для обработки конфиденциальных файлов, необходимых в наших проектах.

Каталог расширений

Популярные теги

Как удалить файл из репозитория git

Добавление, удаление и переименование файлов в репозитории

Добавление файлов в git репозиторий

Удаление файлов из git репозитория и из stage

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

Удаление файлов из git репозитория

Переименование файлов в git репозитории

Как удалить лишние папки и файлы из git репозитория? — Хабр Q&A

Как полностью убрать файлы из .git репозитория?

1 шаг. Закоммитить все изменения

2 шаг. Удалить файлы из кэша репозитория

Очистка всего кэша репозитория

Как убрать из Git-репозитория файлы с конфиденциальной информацией

Минимизация ущерба

▍Коммит пока не отправлен в удалённый репозиторий

▍Коммит отправлен в удалённый репозиторий

Нужно ли создавать новые секретные ключи в том случае, если их актуальные версии попали в публичный репозиторий?

Рекомендации по хранению конфиденциальных файлов в проектах, в которых для контроля версий применяется Git

▍Храните секретные данные в файле .env (или в другом подобном файле)

▍Используйте, если это возможно, ключи API

▍Храните ключи API, пользуясь средствами вашего инструмента для сборки проектов

▍Добавьте запись о файле .env в файл .gitignore

▍Подготовьте шаблонный файл .env.template

▍Не меняйте историю Git в удалённых репозиториях

Итоги

Удаление файлов из репозитория Git? — Хабр Q&A

Git. Удалить файл из репозитория » PacificSky.Ru

git rm - Как удалить файл из репозитория Git?

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

git - удалить файл из репозитория

git - Как удалить файл ТОЛЬКО в удаленном репозитории?

Удаление файлов из истории репозитория

Как полностью удалить файл из репозитория Git

Введение

Несколько методов

Сценарий 1: файл находится в последней фиксации, а вы еще не отправили

1. Вы хотите сохранить файл локально

2. Вы не хотите хранить файл локально

Сценарий 2: файл находится дальше в истории, и вы еще не нажали

Решение 1: BFG Repo-Cleaner

Решение 2. Интерактивная переустановка

Решение 3. Git filter-branch

Сценарий 3: вы уже отправили

Сценарий 4: коммиты уже находятся на GitHub

Смотрите также

**Добавление файлов в git репозиторий**

**Удаление файлов из git репозитория**

**Переименование файлов в git репозитории**