Я автор BFG, я попытаюсь описать то, что я думаю, шаг за шагом, основываясь на вашем аккаунте:
Ручная очистка до BFG...
Ты первый:
закинул все учетные данные в .gitignores и перешел к попытке вычистить их из истории.
В этом описании ваших действий пропущены два важных шага:
Вручную удалить учетные данные из вашего текущего файлового дерева и зафиксировать это изменение в своем репо. Если бы вы этого не сделали, BFG уничтожил бы контент из ваших старых коммитов, но защитил грязь в ваших текущих коммитах. Это поведение описано в документации BFG в разделе «Ваш текущий файлы священны...', и если вы забудете это сделать, BFG выдаст предупреждающее сообщение при запуске ("ВНИМАНИЕ: грязное содержимое выше, может быть удален из других коммитов, но поскольку защищенные коммиты все еще используют его, он ВСЕ ЕЩЕ будет существовать в вашем репозитории..." и т. д. и т. д.). Вы видели это сообщение, когда запускали BFG?
Этот коммит должен быть отправлен в ваш репозиторий GitHub, прежде чем вы клонируете полное зеркало вашего репозитория. Вы забыли этот шаг?
Если вы этого не сделали, это будет означать, что ваши учетные данные не были полностью удалены из вашего репозитория.
Первый раз запускаю BFG...
Идем дальше, тогда вы:
- сделал свежий зеркальный клон вашего репо с GitHub
- запустил BFG, фильтруя с помощью параметра
--delete-files (вы видели предупреждение о защищенном содержимом?)
- отправил обновленный репозиторий на GitHub
...в какой момент:
Судя по логам терминала, он обновил репо. Пока все хорошо, верно? Я вхожу в свою учетную запись github и после нескольких щелчков нахожу учетные данные, все еще там, файл и все, в моей истории.
Итак, если предположить, что вы удали правильно вручную удалить плохой контент из своих последних коммитов перед запуском BFG, то, что вы увидели, довольно странно. Некоторые возможные причины:
а) Репозиторий не был клонирован с флагом --mirror, поэтому не все ветки на GitHub были перезаписаны, оставляя грязную историю в неглавных ветках. Однако вы прямо заявили, что использовали флаг --mirror.
б) Даже при зеркальной отправке на GitHub старые коммиты по-прежнему доступны там, если на них ссылается явный идентификатор коммита (т. е. URL-адрес GitHub, в котором есть идентификатор коммита), вплоть до момента GitHub выполняет автоматическую сборку мусора в вашем репозитории. Пулл-реквесты и форки также могут сохранить коммиты из старой истории. Это было бы еще одним возможным объяснением грязных коммитов, которые вы видели.
Запускаю BFG во второй раз...
В любом случае, в тот момент вы были обеспокоены, и:
- снова запустил BFG, на этот раз с
--replace-text passwords.txt, который обновляет содержимое файла, а не удаляет его целиком.
Опять же, в журналах BFG указано, что было исправлено несколько случаев. Я нажимаю, проверяю, а учетные данные все еще там, сидят в Github.
Немного любопытно, что BFG сказал, что было больше контента, который нужно удалить - возможно, ваши учетные данные были в большем количестве мест, чем вы думали, - но в любом случае, какой бы ни была причина, по которой вы видели их все еще после первого запуска, это по той же причине, по которой вы видели их после второго прогона.
Возвращение к работе
В этот момент я сдаюсь и пытаюсь вернуться к работе, думаю, я разберусь с этим позже.
Итак, на данный момент вы переписали историю своего репозитория Git (дважды!) и отправили ее на GitHub. Но в вашей учетной записи не упоминается, что вы удалили все свои локальные старые копии репозитория, как указано в инструкциях BFG:
"На данный момент вы готовы к тому, что все избавятся от своих старых копий репозитория и создадут новые клоны новых, нетронутых данных".
Итак, вы удалили свою старую рабочую копию репозитория Git на своем рабочем компьютере и повторно клонировали с новой историей репозитория Git? История в вашем старом репозитории будет отличаться от "очищенной" истории, которая была бы представлена в GitHub на тот момент (даже если "очищенная" история не была такой "очищенной", как вы хотели бы). понравилось!).
Я делаю какую-то работу, пытаюсь подтолкнуть, получаю странный конфликт слияния (вы на 50 впереди и на 50 позади по коммитам).
Если бы вы выполняли работу в старой локальной копии вашего репозитория Git (а не в свежем повторном клоне из GitHub), то вы бы увидели это. По сути, вы отправляете на GitHub 50 коммитов со старой, грязной историей, а для Git вы, кажется, в блаженном неведении о том, что в этой ветке уже есть 50 совершенно разных (для Git, который заботится только об идентификаторах коммитов) коммитов. Git думает, что вы делаете немного странно («на 50 вперед и на 50 позади») и пытается вам это сказать.
Делать хуже...
Какая? Я пытаюсь вытащить и объединить, и вдруг каждый коммит в моей истории git дублируется по имени, а некоторые из них просто пусты. Я проверяю свой сетевой график Github, и похоже, что есть вторая ветвь, начинающаяся с моего первоначального коммита, которая точно отражает все мои коммиты, которые были застегнуты с моим последним коммитом.
Итак, выполнив извлечение и слияние, вы объединили очищенную историю и грязную историю, объединив их с помощью коммита слияния. С точки зрения разбора вашей истории, это плохая идея. Лучшей идеей было бы перебазировать вашу новую работу поверх очищенной истории, нажать ее, удалить старое рабочее репо и сделать новый клон.
Последствия
Когда я сейчас пытаюсь запустить BFG с самого начала, заново клонируя и зеркалируя репозиторий, он мне говорит, что в нем нет учетных данных, несмотря на то, что я их вижу в Github.
Это довольно странно, но на самом деле у меня нет никакого объяснения этому, кроме ошибки оператора, помимо объяснения «GitHub gc», уже приведенного выше. Вы можете поделиться со мной репозиторием (если хотите), чтобы я мог провести более детальную проверку, или просто пришлите мне заархивированную копию каталога '.bfg-report', чтобы я мог увидеть, какую диагностику BFG зафиксировал при его выполнении.
Восстановление
Мне действительно не помешала бы некоторая помощь в понимании того, что произошло, и как, если вообще, я могу вернуться к прежнему положению вещей.
Надеюсь, мне удалось объяснить кое-что из того, что произошло.
Что касается сортировки вашей истории (т.е. избавления от этих двух повторяющихся цепочек), вам нужно сбросить историю Git обратно до (очищенной) точки, прежде чем вы добавили этот коммит слияния. Посмотрите на фиксацию слияния и определите, какую родительскую историю вы предпочитаете. Какая последняя фиксация (xxxx) в этой истории перед слиянием?
git reset --hard master xxxx
Это вполне может привести к потере последней части вашей старой, грязной истории. Определите этот коммит (yyyy) и перебазируйте его поверх вашей истории или просто выберите его:
git cherry-pick yyyy
Наконец, отправьте восстановленную историю на GitHub с флагом «force»:
git push origin master -f
... заархивируйте архив вашего старого репо, а затем удалите все старые локальные копии вашего репо, чтобы не запутаться еще больше. Сделай свежий клон.
03.07.2014
