Видалити файл зі сховища git (історія)

(вирішено, див. нижню частину корпусу питання)
Шукаю це вже давно, і я маю до цього часу:

• http://dound.com/2009/04/git-forever-remove-files-or-folders-from-history/ та
• http://progit.org/book/ch9-7.html

Приблизно той самий метод, але обидва вони залишають об'єкти у файлах пакунків ... Застрягли.
Що я спробував:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch file_name'
rm -Rf .git/refs/original
rm -Rf .git/logs/
git gc

У пакеті все ще є файли, і ось як я це знаю:

git verify-pack -v .git/objects/pack/pack-3f8c0...bb.idx | sort -k 3 -n | tail -3

І це:

git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch file_name" HEAD
rm -rf .git/refs/original/ && git reflog expire --all &&  git gc --aggressive --prune

Так само...

Спробував git cloneфокус, він видалив деякі файли (~ 3000 з них), але найбільші файли все ще там ...

У мене є кілька великих застарілих файлів у сховищі, ~ 200M, і я справді не хочу їх там ... І я не хочу скидати сховище на 0 :(

РІШЕННЯ: Це найкоротший спосіб позбутися файлів:

1. перевірте .git / packed-refs - моя проблема полягала в тому, що у мене був refs/remotes/origin/masterрядок для віддаленого сховища, видаліть його, інакше git не видалить ці файли
2. (необов’язково) git verify-pack -v .git/objects/pack/#{pack-name}.idx | sort -k 3 -n | tail -5 - для перевірки найбільших файлів
3. (необов’язково) git rev-list --objects --all | grep a0d770a97ff0fac0be1d777b32cc67fe69eb9a98 - щоб перевірити, що це за файли
4. git filter-branch --index-filter 'git rm --cached --ignore-unmatch file_names' - видалити файл із усіх версій
5. rm -rf .git/refs/original/ - видалити резервну копію git
6. git reflog expire --all --expire='0 days' - закінчити термін дії всіх вільних предметів
7. git fsck --full --unreachable - перевірити, чи немає вільних предметів
8. git repack -A -d - перепакування
9. git prune - остаточно видалити ці предмети

Я не можу сказати напевно без доступу до даних вашого сховища, але я вважаю, що, ймовірно, є одне або декілька упакованих посилань, які все ще посилаються на старі коміти до того, як ви запускали git filter-branch. Це пояснювало б чомуgit fsck --full --unreachable велика крапка не називається недосяжним об’єктом, навіть якщо ви закінчили термін дії перезапису та видалили оригінальні (розпаковані) посилання.

Ось що я б зробив (після того, як git filter-branchі git gcщо було зроблено):

1) Переконайтесь, що оригінальні посилання зникли:

rm -rf .git/refs/original

2) Термін дії всіх записів перезапису закінчується:

git reflog expire --all --expire='0 days'

3) Перевірте наявність старих упакованих реф

Це може бути складно, залежно від кількості упакованих реф. Я не знаю жодної команди Git, яка автоматизує це, тому я думаю, вам доведеться робити це вручну. Зробіть резервну копію .git/packed-refs. Тепер редагуйте .git/packed-refs. Перевірте наявність старих посилань (зокрема, подивіться, чи не упаковано якесь із цих посилань .git/refs/original). Якщо ви знайдете якісь старі, які не повинні бути там, видаліть їх (видаліть рядок із цим посиланням).

Після завершення очищення packed-refsфайлу перевірте, чи git fsckпомічає недосяжні об’єкти:

git fsck --full --unreachable

Якщо це спрацювало, і git fsckтепер ваша велика крапка повідомляється як недосяжна, ви можете перейти до наступного кроку.

4) Перепакуйте запаковані архіви

git repack -A -d

Це гарантуватиме, що недосяжні предмети розпаковуються та залишаються розпакованими.

5) Обрізати вільні (недосяжні) предмети

git prune

І це має зробити це. Git дійсно повинен мати кращий спосіб керувати запакованими посиланнями. Можливо, є кращий спосіб, про який я не знаю. За відсутності кращого способу, ручне редагування packed-refsфайлу може бути єдиним шляхом.

Я рекомендую використовувати BFG Repo-Cleaner - простішу, швидшу альтернативу git-filter-branchспеціально розробленій для перезапису файлів з історії Git. Одним із способів полегшити ваше життя тут є те, що він фактично обробляє всі посилання за замовчуванням (усі теги, гілки, речі, такі як refs / remotes / origin / master тощо), але це також 10-50x швидше.

Вам слід уважно виконати ці кроки тут: http://rtyley.github.com/bfg-repo-cleaner/#usage - але основний біт якраз такий: завантажте jar BFG (потрібна Java 6 або новіша версія ) і запустіть цю команду :

$ java -jar bfg.jar  --delete-files file_name  my-repo.git

Будь-який файл з іменем file_name(якого немає у вашому останньому коміті) буде повністю видалено з історії вашого сховища. Потім ви можете використовувати git gcдля очищення мертвих даних:

$ git gc --prune=now --aggressive

BFG, як правило, набагато простіший у використанні, ніж git-filter-branch- варіанти розроблені для цих двох типових випадків використання:

• Видалення божевільних великих файлів
• Видалення паролів, облікових даних та інших приватних даних

Повне розкриття інформації: Я автор BFG Repo-Cleaner.

Я виявив, що це дуже корисно щодо видалення цілої папки, оскільки вищесказане мені насправді не допомогло: https://help.github.com/articles/remove-sensitive-data .

Я використав:

git filter-branch -f --force \
--index-filter 'git rm -rf --cached --ignore-unmatch folder/sub-folder' \
--prune-empty --tag-name-filter cat -- --all

rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now

Я намагався позбутися великого файлу в історії, і наведені вище відповіді працювали до певного моменту. Справа в тому, що вони не працюють, якщо у вас є теги. Якщо коміт, що містить великий файл, доступний з тегу, то вам потрібно буде таким чином відрегулювати команду filter-branch:

git filter-branch --tag-name-filter cat \
--index-filter 'git rm --cached --ignore-unmatch huge_file_name' -- \
--all --tags

Дивіться: Як видалити конфіденційні файли з історії git

Вищезазначене не вдасться, якщо файл не існує у версії rev. У такому випадку перемикач '--ignore-unmatch' це виправить:

git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch <filename>' HEAD

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

git gc --prune='0 days ago'

У вас є різні причини для великого розміру репозиторію git після git gc, оскільки він не видаляє всі вільні об'єкти .

Я детально описую ці причини в " зменшенні розміру сховища git "

Але одним трюком для перевірки у вашому випадку було б клонування вашого "очищеного" репозиторію Git і перевірку, чи має клон відповідний розмір.

("" очищений "репо - це той, де ви застосовували filter-branch, а потім gcі prune)

Це повинно бути висвітлено git obliterateкомандою в Git Extras ( https://github.com/visionmedia/git-extras ).

git obliterate <filename>

У мене була та сама проблема, і я знайшов чудовий підручник з github, який покроково пояснює, як позбутися файлів, випадково скоєних вами.

Ось невеликий підсумок процедури, як запропонував Кекс.

Якщо у вас є файл з іменем file_to_removeдля видалення з історії:

cd path_to_parent_dir

git filter-branch --force --index-filter \
  'git rm --cached --ignore-unmatch file_to_remove' \
  --prune-empty --tag-name-filter cat -- --all