TL; DR
Вы должны получить GitHub, чтобы делать то, что вам нужно. Даже тогда, если коммиты были скопированы в другие репозитории в другом месте, вы должны затем получить все эти другие копии (и люди, которые владеют ими), чтобы обновить их копии тоже.
Long
Ничто - нет энергии на земле - на самом деле не может удалить файл из коммитов, которые содержат файл. Ничто не может изменить любой существующий коммит, никогда. Как только коммит сделан, он фактически устанавливается в камне или замораживается навсегда.
Вместо этого BFG и git filter-branch делают новые и улучшенные коммиты, копирование коммитов, которые имеют файл, в новые, которые не имеют. (Тот факт, что у новых коммитов нет файла , является улучшением, в данном случае.)
Пока это довольно просто. Старые коммиты все еще там, и теперь новые тоже там. Но вы хотите, чтобы старые исчезли . Здесь все идет не так. Здесь также все немного усложняется.
Вопрос, который вы должны задать в этот момент:
- Как Git находит коммит в первую очередь?
- Кстати, как кто-нибудь находит коммит? Каково истинное имя коммита?
У вас есть четыре ссылки выше, и одна из них https://github.com/luivilella/git-test-removing-sensitive-data/tree/124e5707bf29a24cfb4167c869250fd919c42446. Я оставляю полный URL, который будет показан здесь. Обратите внимание на очень длинную строку случайных шестнадцатеричных цифр в конце, 124e5707bf29a24cfb4167c869250fd919c42446. Это коммит га sh ID . Это
Это истинное имя коммита. Это , как тот, кто имеет коммит, может найти его надежно, каждый раз. Вы просто должны запомнить 124eblahblah (трудно) или записать его где-нибудь, вырезать и вставить его (легко) и запустить git checkout <em>hash-id</em>, и он у вас есть и готов к работе.
Теперь, каждый репозиторий, включая каждый клон какого-либо оригинального репозитория, содержит в себе каждый коммит, который он когда-либо брал, минус любой, который он выбрасывает. Обратите внимание, что BFG завершил свою сессию советом: Это служебная программа, или, точнее, директор отдельных служебных программ, которые go вокруг ищут коммиты и другие Git объекты, которые никто не мог найти . Если вы не можете найти объект - если его ha sh ID не записан нигде, что Git может видеть - тогда вам, очевидно, все равно, удалится ли Grim Collector это полностью.
Так что теперь мы должны спросить:
- Где можно записать эти идентификаторы ha sh, чтобы Git мог их видеть?
Для самого Git ответ в основном: В других коммитах . Каждый коммит может перечислять некоторые другие идентификаторы ha sh коммитов. Если фиксация с ха sh H списками фиксирует фиксацию ha sh ID G , то любой, кто сможет найти H , может использовать это для поиска G . Если в коммите, чей идентификатор ha sh равен G , указан идентификатор коммита ha sh F , то любой с H или G можно найти F .
Если вы хотите нарисовать его, нарисуйте коммит с некоторым количеством стрелок, выходящих из него. Это родительский коммит, имеющий sh ID в коммите. У большинства коммитов ровно один. У коммитов слияния есть два, для их двух родителей. 1 Эти стрелки всегда указывают назад , на какой-то предыдущий коммит. Так что, если вы можете просто найти последний коммит (ы), вы можете найти каждый коммит.
Здесь такие вещи, как имена ветвей (master), приходят имена тегов (v1.2) и имена для удаленного отслеживания (origin/master). Git дает вам эти устройства именования для поиска одного указанного c commit . 2 С именем ветви, это последний коммит, который, как мы должны сказать, является частью ветви. С любым другим именем, это просто какой-то идентификатор ha sh, например тег может пометить конкретный коммит как «используйте этот коммит для доступа к версии 1.2».
Все эти имена в совокупности refs или ссылки . Когда BFG сказал:
Обновление 6 ссылок
это то, о чем он говорил. BFG скопировал некоторых оригинальных коммитов на новые и улучшенные. Затем, скопировав их, он должен был скопировать также все последующие коммиты, либо улучшив их тоже (потому что у них был файл, который вы хотите удалить), либо просто потому, что старые имели идентификатор ha sh некоторые другие старые и плохие коммиты, которые теперь были улучшены.
Однажды BFG скопировал и улучшил все, что должно быть улучшено, и скопировал все остальное, что должно быть скопировано из-за копирования и улучшения, BFG входит и меняет каждый ref соответственно.
Но BFG может изменять только ссылки в вашем хранилище. Каждый существующий репозиторий Git имеет свои собственные ссылки. Все Gits share фиксирует (копируя), но они не обязательно разделяют все свои ссылки.
Имея обновил ссылки в вашем собственном репозитории. BFG теперь рекомендует вам очистить ваши Git reflogs , в которых хранятся журналы того, что ref ha sh ID было (и, конечно, Git может видеть все это, так что они сохраняют старые коммиты живыми). Это команда git reflog expire. Часть --expire=now говорит, что не хранит записи в течение 30 или 90 дней: удалите их все сейчас. Затем BFG рекомендует запустить служебную программу git gc. --prune=now удаляет стандартный 14-дневный льготный период, который используется Git, чтобы фоновые git gc операции не удаляли объект, который находится в середине какой-либо другой команды Git в середине make . 3
Таким образом, после этого шага в вашем хранилище больше нет «плохих» коммитов. Если вы попытаетесь git checkout <em>hash</em>, ваш Git скажет: Похоже, у меня нет идентификатора ha sh в моей базе данных объектов. Его больше нет! Все хорошо.
Но это ваш Git репозиторий. Итак, теперь вы используете git push origin --force: здесь ваш Git вызывает другой Git - тот, что находится на GitHub - и дает им любые новые объекты (коммиты и внутренние объекты), которые им понадобятся, такие как новые и улучшенные объекты, которые BFG сделал. Затем ваш Git отправляет принудительные команды: Для имени ветви master, установите это имя ветви для запоминания коммита X! Для имени тега v1.2 установите для этого имени тега запоминание commit Q! и т. Д.
Если они подчиняются (что они будут делать, если у вас есть необходимые разрешения) ), теперь GitHub Git может найти эти коммиты только по этим именам. Эти коммиты могут найти более ранние коммиты и так далее. Но GitHub Git не не удалил других коммитов. Они сделают это, когда их Git получит возможность запустить git gc, когда бы это ни было. Более того, у них могут быть имена реферов, о которых они вам никогда не говорили.
Упомянутые вами здесь запросы на получение . GitHub реализует запросы извлечения, устанавливая специальные имена только для GitHub, refs/pull/*. Они копируют эти имена в другие репозитории на стороне GitHub, когда это уместно, согласно всем правилам, которые заставляют GitHub работать. Но они не позволяют вам устанавливать их или удалять их. См. Также Удаление закрытого запроса извлечения из GitHub .
Итак: вы должны связаться со службой поддержки GitHub и получить им , чтобы удалить любые PR, поддерживающие «плохие» коммиты. , Вы должны заставить их Git запустить соответствующий git gc, чтобы отменить коммиты до того, как пройдет окно обслуживания по умолчанию. Только тогда перестанут работать URL, которые ссылаются на эти PR или коммиты с идентификатором ha sh. И, конечно, вы должны помнить, что любой, кто может клонировать или получить доступ к вашему репозиторию GitHub, возможно, уже скопировал эти коммиты в свой собственный репозиторий и может иметь ваши данные: и единственный способ получить их отдать это значит go им, кем бы они ни были.
1 Некоторые коммиты слияния, которые Git вызывают слияния осьминога , может иметь более двух родителей. Стрелки все еще обязательно указывают назад.
2 Имена тегов могут указывать непосредственно на другие Git внутренние объекты, такие как деревья или пятна . Деревья - это то, как Git хранит имена файлов, которые go с фиксацией, а blobs - это то, как Git хранит содержимое файлов - данные для каждого файла. Имя тега также может указывать на последний из внутренних типов объектов Git, который является аннотированным тегом 1234 *. Аннотированный тег-объект содержит идентификатор ha sh некоторого ранее существующего объекта, а также, конечно, аннотации.
3 Когда Git строит new фиксация или другие данные, благодаря этому льготному периоду, это значительно упрощается. Git может просто создавать объекты влево и вправо, получая новые га sh идентификаторы, которые есть только у одной программы на данный момент: ни одна не сохраняется нигде и ни один из этих объектов не может быть найден. Затем, в конце, когда все готово, создатель объекта записывает самый важный идентификатор ha sh - например, для last commit в ветви - в какую-то ссылку. Теперь все объекты доступны для поиска, и процесс завершен.
Если что-то go неправильно - Git обнаруживает, что по какой-то причине не может быть выполнено какое-либо принятие, например, объекта-создания Программа может просто выйти сразу. Любые объекты, которые он сделал, которые не используются, будут сидеть без дела в течение льготного периода, а затем следующий прогон git gc, всякий раз, когда это - Git запускает его автоматически для вас, так что вам не нужно об этом думать - будет найти и удалить остатки мусора.