Видаліть конфіденційні файли та їх коміти з історії Git

Я хотів би поставити проект Git на GitHub, але він містить певні файли з конфіденційними даними (імена користувачів та паролі, наприклад /config/deploy.rb для capistrano).

Я знаю, що можу додати ці імена файлів до .gitignore , але це не видалить їхню історію в Git.

Я також не хочу починати заново, видаляючи каталог /.git.

Чи є спосіб видалити всі сліди певного файлу з вашої історії Git?

З усіх практичних цілей, перше , про що слід потурбуватись, - це ЗМІНА ВАШИХ ПАРОЛІВ! З вашого запитання незрозуміло, чи ваше сховище git повністю локальне, чи у вас ще є віддалене сховище в іншому місці; якщо він віддалений і не захищений від інших, у вас є проблеми. Якщо хтось клонував це сховище перед тим, як виправити це, він отримає копію ваших паролів на локальній машині, і немає ніякого способу змусити їх оновити до вашої "фіксованої" версії, коли він пішов з історії. Єдине безпечне, що ви можете зробити - це змінити пароль на щось інше, де б ви його не використовували.

Ось це не виходить, ось як це виправити. GitHub відповів саме на це запитання як FAQ :

Примітка для користувачів Windows : використовуйте подвійні лапки (") замість синглів у цій команді

git filter-branch --index-filter \
'git update-index --remove PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA' <introduction-revision-sha1>..HEAD
git push --force --verbose --dry-run
git push --force

Оновлення 2019 року:

Це поточний код із FAQ:

  git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA" \
  --prune-empty --tag-name-filter cat -- --all
  git push --force --verbose --dry-run
  git push --force

Майте на увазі, що як тільки ви перемістили цей код у віддалене сховище, наприклад, GitHub та інші, клонували це віддалене сховище, зараз ви потрапили в ситуацію, коли ви переписуєте історію. Коли інші спробують зняти ваші останні зміни після цього, вони отримають повідомлення про те, що зміни не можна застосувати, оскільки це не швидкий перемотка вперед.

Щоб виправити це, їм доведеться або видалити існуючий сховище, і його повторно клонувати, або дотримуватися вказівок у розділі "ВІДНОВЛЕННЯ ВІДГОТОВЛЕНОГО ЗВ'ЯЗКУ" на сторінці git-rebase .

Порада : Виконатиgit rebase --interactive

Надалі, якщо ви випадково вчинили якісь зміни з конфіденційною інформацією, але помітили, перш ніж переходити до віддаленого сховища, є деякі простіші виправлення. Якщо ви востаннє зобов'язуєтеся додати конфіденційну інформацію, ви можете просто видалити конфіденційну інформацію та виконати:

git commit -a --amend

Це дозволить внести зміни до попереднього зобов’язання з будь-якими новими внесеними вами змінами, включаючи цілі видалення файлів, виконані за допомогою git rm. Якщо зміни надалі повернулися в історію, але все ще не пересунуті до віддаленого сховища, ви можете зробити інтерактивну базу даних:

git rebase -i origin/master

Це відкриває редактор із зобов’язаннями, які ви зробили з моменту останнього спільного предка з віддаленим сховищем. Змініть "Вибрати" на "редагувати" в будь-яких рядках, що представляють комісію з конфіденційною інформацією, та збережіть та вийдіть із системи. Git пройде через зміни і залишить вас там, де ви можете:

$EDITOR file-to-fix
git commit -a --amend
git rebase --continue

Для кожної зміни з конфіденційною інформацією. Врешті-решт, ви знову опинитесь у своєму відділенні, і зможете спокійно натиснути нові зміни.

Зміна паролів - хороша ідея, але для процесу видалення пароля з історії вашого репо я рекомендую BFG Repo-Cleaner - більш швидку і просту альтернативу, git-filter-branchявно розроблену для видалення приватних даних з Git repos.

Створіть private.txtфайл із зазначенням паролів тощо, які потрібно видалити (один запис у рядку), а потім запустіть цю команду:

$ java -jar bfg.jar  --replace-text private.txt  my-repo.git

Усі файли з розміром порогового значення (1 МБ за замовчуванням) в історії вашого репо будуть скановані, а будь-яка відповідна рядок (що не є у вашому останньому комітеті) буде замінена рядком "*** ВЗАЄМО ***". Потім можна використовувати git gcдля очищення мертвих даних:

$ git gc --prune=now --aggressive

BFG, як правило, на 10-50 разів швидше, ніж працює, git-filter-branchі параметри спрощені та адаптовані навколо цих двох загальних випадків використання:

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

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

Якщо ви натиснули на GitHub, примусового натискання недостатньо, видаліть сховище або зв’яжіться зі службою підтримки

Навіть якщо ви змушуєте натиснути одну секунду після цього, цього недостатньо, як пояснено нижче.

Єдиними дійсними напрямками дії є:

• це те, що просочилося змінним обліковим записом, як пароль?

  • так: негайно змініть свої паролі та подумайте про використання більше ключів OAuth та API!

  • ні (голі фотографії):

    • чи вам байдуже, якщо всі проблеми в сховищі будуть зведені нанівець?

      • ні: видаліть сховище

      • так:

        • зверніться в службу підтримки
        • якщо витік дуже важливий для вас, до того, що ви готові отримати деякий час простою сховища, щоб зменшити його швидкість, зробіть його приватним, поки ви будете чекати, коли підтримка GitHub відповість вам

Сила натискання секунди пізніше недостатня, оскільки:

• GitHub тривалий час тримає звисаючі зобов’язання.

  Співробітники GitHub мають право видаляти такі звисаючі зобов’язання, якщо ви зв’яжетеся з ними.

  Я відчув це з першої руки, коли я завантажив усі повідомлення GitHub на репо, вони попросили мене зняти його, і я це зробив gc. Однак вилучення запитів, що містять дані , потрібно видалити : дані репо-файлу залишалися доступними до року після початкового зняття через це.

  Помилкові коміти можна побачити через:

  • веб-інтерфейс фіксації: https://github.com/cirosantilli/test-dangling/commit/53df36c09f092bbb59f2faa34eba15cd89ef8e83 ( Wayback machine )
  • API: https://api.github.com/repos/cirosantilli/test-dangling/commits/53df36c09f092bbb59f2faa34eba15cd89ef8e83 ( машина Wayback )

  Одним із зручних способів отримати джерело на цій комісії - це використовувати метод завантаження zip, який може приймати будь-яку посилання, наприклад: https://github.com/cirosantilli/myrepo/archive/SHA.zip

• Отримати відсутні SHA можна за допомогою:

  • перелік подій API з type": "PushEvent". Наприклад, міна: https://api.github.com/users/cirosantilli/events/public ( машина зворотного зв'язку )
  • зручніше іноді, дивлячись на SHA запитів на виклик, які намагалися видалити вміст

• Є скраппери на зразок http://ghtorrent.org/ та https://www.githubarchive.org/, які регулярно збирають дані GitHub і зберігають їх в інших місцях.

  Я не міг знайти, якщо вони скребкують фактичну фіксацію різниці, і це малоймовірно, оскільки було б занадто багато даних, але це технічно можливо, і в АНБ та друзях, ймовірно, є фільтри, щоб архівувати лише речі, пов’язані з людьми чи об’єктами, що цікавлять.

Якщо ви видалите сховище замість того, щоб просто натиснути примусово, коміти зникають навіть з API негайно і дають 404, наприклад https://api.github.com/repos/cirosantilli/test-dangling-delete/commits/8c08448b5fbf0f891696819f3b2b2d653f7a3824. Це працює навіть якщо ви відтворили інше сховище з такою ж назвою.

Щоб перевірити це, я створив репо: https://github.com/cirosantilli/test-dangling і зробив:

git init
git remote add origin git@github.com:cirosantilli/test-dangling.git

touch a
git add .
git commit -m 0
git push

touch b
git add .
git commit -m 1
git push

touch c
git rm b
git add .
git commit --amend --no-edit
git push -f

Дивіться також: Як видалити звисаючу комітку з GitHub?

Я рекомендую цей сценарій Девіда Андерхілла, який працював як шарм для мене.

Ці команди додають додатково фільтр-гілку natacado, щоб очистити безлад, який він залишає після себе:

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

Повний сценарій (весь кредит на Девіда Андерхілла)

#!/bin/bash
set -o errexit

# Author: David Underhill
# Script to permanently delete files/folders from your git repository.  To use 
# it, cd to your repository's root and then run the script with a list of paths
# you want to delete, e.g., git-delete-history path1 path2

if [ $# -eq 0 ]; then
    exit 0
fi

# make sure we're at the root of git repo
if [ ! -d .git ]; then
    echo "Error: must run this script from the root of a git repository"
    exit 1
fi

# remove all paths passed as arguments from the history of the repo
files=$@
git filter-branch --index-filter \
"git rm -rf --cached --ignore-unmatch $files" HEAD

# remove the temporary history git-filter-branch
# otherwise leaves behind for a long time
rm -rf .git/refs/original/ && \
git reflog expire --all && \
git gc --aggressive --prune

Останні дві команди можуть працювати краще, якщо їх змінити на наступні:

git reflog expire --expire=now --all && \
git gc --aggressive --prune=now

Щоб було зрозуміло: прийнята відповідь правильна. Спробуйте спочатку. Однак це може бути надмірно складним для деяких випадків використання, особливо якщо ви стикаєтесь з нечесними помилками, такими як "фатальна: погана ревізія - порожній-порожній", або насправді не цікавить історія вашого репо.

Альтернативою може бути:

1. cd до базової галузі проекту
2. Видаліть чутливий код / ​​файл
3. rm -rf .git / # Видаліть всю інформацію про git зі свого коду
4. Перейдіть до github і видаліть своє сховище
5. Дотримуйтесь цього керівництва, щоб перенести свій код до нового сховища, як зазвичай - https://help.github.com/articles/adding-an-existing-project-to-github-using-the-command-line/

Це, звичайно, видалить усі гілки історії фіксування та проблеми як з вашого github repo, так і з місцевого git repo. Якщо це неприйнятно, вам доведеться використовувати альтернативний підхід.

Назвіть це ядерним варіантом.

Можна використовувати git forget-blob.

Використання досить просте git forget-blob file-to-forget. Більше інформації ви можете отримати тут

https://ownyourbits.com/2017/01/18/completely-remove-a-file-from-a-git-repository-with-git-forget-blob/

Він зникне з усіх зобов’язань у вашій історії, рефлогування, тегів тощо

Раз у раз я стикаюся з однією і тією ж проблемою, і кожен раз, коли мені доводиться повертатися на цю посаду та інші, саме тому я автоматизував процес.

Кредити для учасників програми «Переповнення стека», які дозволили мені скласти це разом

Ось моє рішення у Windows

git filter-branch --tree-filter "rm -f" fileir / filename "" HEAD

git push - сила

переконайтеся, що шлях правильний, інакше він не працюватиме

Я сподіваюся, що це допомагає

Використовуйте фільтр-гілку :

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

git push origin *branch_name* -f

Мені довелося це робити кілька разів на сьогодні. Зауважте, що це працює лише за 1 файл одночасно.

1. Отримайте список усіх комісій, які змінили файл. Той, хто знаходиться внизу, здійснить перше виконання:

   git log --pretty=oneline --branches -- pathToFile

2. Щоб видалити файл з історії, використовуйте перший фіксатор sha1 та шлях до файлу з попередньої команди та заповніть їх у цій команді:

   git filter-branch --index-filter 'git rm --cached --ignore-unmatch <path-to-file>' -- <sha1-where-the-file-was-first-added>..

Отже, це виглядає приблизно так:

git rm --cached /config/deploy.rb
echo /config/deploy.rb >> .gitignore

Видаліть кеш відстежуваного файлу з git та додайте цей файл до .gitignoreсписку

У своєму проекті для Android я мав admob_keys.xml як розділений файл xml у папці app / src / main / res / values ​​/ . Щоб видалити цей чутливий файл, я використав сценарій нижче і працював ідеально.

git filter-branch --force --index-filter \
'git rm --cached --ignore-unmatch  app/src/main/res/values/admob_keys.xml' \
--prune-empty --tag-name-filter cat -- --all