BFG удаляет чувствительный контент повсюду, но в предпоследнем фиксации

Question

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

Я использовал для этой цели удивительный инструмент, который является очистителем репозитория BFG, который я также использовал в прошлом, чтобы удалить целые остаточные и чувствительные файлы из моей истории git. На этот раз следующий the instructions заменить текст:

$ java -jar ~/bfg.jar --replace-text tokens.txt myRepo.git 

Но на выходе, это появилось:

... 
* commit 10134503 (protected by 'HEAD') - contains 1 dirty file : 
- app.py (640 B) 
... 
If you *really* want this content gone, make a manual commit that removes it, 
and then run the BFG on a fresh copy of your repo. 

Так что я сделал именно это, клонируют все это, сделал совершить замену двух линий, которые я хотел ушел за 2 звонка на os.environ[] на python и нажал его. Затем я снова побежал BFG, git reflog, и все, казалось, работало как шарм.

Я проверил в gitlab-х совершившим браузер, и текст был ***REMOVED*** везде но в предпоследний коммит, где это произошло:

Я предполагаю, что это произошло потому, что файл редактируется в следующем commit (теперь тот, который защищен «HEAD»), и GIT нуждаются в этих токенах, чтобы воссоздать изменения, которые я сделал, чтобы избавиться от этих двух строк. Но тогда, как мне это достичь?

Answer 1

Перезапись истории Git - сложный бизнес, где пользователям очень легко делать неясные ошибки, которые отрицают то, что они пытаются сделать. Как автор BFG, я провел lotoftime оценивал отчеты пользователей, пытаясь понять, почему произошло странное. BFG - это лишь средний шаг в процессе очистки репо, и есть много возможностей для пользовательской ошибки в шагах до и после - довольно редко, что на самом деле есть ошибка в самом BFG *.

Так что, если я понимаю ваше описание правильно, ваша история фиксации теперь выглядит следующим образом (самый старый первый, самый новый последний):

• ...cleaned commits containing ***REMOVED*** where the credentials used to be
• a penultimate commit where the unwanted credentials *are* present
• the 'manual' cleaning commit where you instead read credentials from os.environ[]

Lets посмотрите на ваши действия:

Итак, я сделал именно это, клонировал все это, сделал фиксацию, заменяя две строки, которые я хотел убрать, на 2 вызова os.environ [] на python и нажал ее. [X] Затем я снова пробежал BFG, git reflog и все, казалось, работало как шарм. [Y]

Дело в том, ваша история коммитов в GitLab на X будет именно то, что вы сообщите ваш окончательный история коммитов в GitLab есть.Таким образом, между X и Y ничего не изменилось в GitLab.

Итак, два возможных объяснения:

• Там есть ошибка в BFG (as @torek suggested) - Я хотел бы видеть простой тест демонстрирует эту
• окончательный git push в Y просто Ждут» t произошло или не было выполнено, например, потому что --force не использовался.

Если вы могли бы попробовать запустить BFG снова на новом зеркальном клоне вашего репо, мы могли бы устранить один из этих вариантов.

Наконец:

Я предполагаю, что это произошло потому, что файл редактируется в следующей фиксации (теперь один защищенный «голова») и GIT нужны эти маркеры, чтобы воссоздать изменения, которые я сделал, чтобы избавиться из этих 2 строк.

Магазины Git фиксируют как полные снимки вашего дерева файлов с каждой фиксацией, они не хранят их как разницу, которую вы могли бы подумать, что она будет использоваться. . Так что не волнуйтесь, Git не нужны эти старые учетные данные, чтобы создать окончательный ручной фиксации (где учетные данные считываются из os.environ[])

Кстати, BFG был разработан с 'reformed-alcoholic' model поведения пользователя - вы «повторно только предполагается запустить BFG, как только вы поняли, у вас есть проблемы и очистить себя. - поэтому убедитесь, что последний коммит в репозитории является чистым перед запуском BFG

* есть определенно условия, при которых BFG умирает с фатальным исключением, но ошибок нет, я знаю, где BFG фактически завершил прогон и вел себя снаружи -of-спецификации.