Git: удалить учетные данные из репозитория

Во-первых: это (надеюсь) не дубликат this или это.

Текущее состояние: я зафиксировал файл с учетными данными для внутренней базы данных в своем репозитории Git. Это было нормально, так как я использовал его только один. Затем моя группа начала клонировать, толкать и тянуть в этом проекте. Теперь у нас есть несколько репозиториев Git (один центральный и несколько для разработчиков).

Проблема: теперь мы хотим предоставить публичный доступ к исходному коду и репозиторию Git или, по крайней мере, позволить Git управлять сведениями о других участниках кода.

Вопрос: Какова была бы хорошая стратегия для

а) удалить файл с учетными данными из центрального или из всех репозиториев, или

б) настроить новый репозиторий Git как своего рода «интерфейс» с внешним миром?

Если выбрать (b), как мы можем легко передать изменения обратно в основной репозиторий?

Из-за уже широко распространенного распространения нам бы очень хотелось не делать git rebase или git filter-branch для каждого текущего репозитория.


git credentials
person Boldewyn    schedule 01.02.2010    source источник

Ответы (4)


arrow_upward
10
arrow_downward

Извините, но вы застряли с запуском git filter-branch, если хотите удалить учетные данные из основного репозитория. См. статью Удаление конфиденциальных данных, написанную сотрудниками GitHub.

Из-за дизайна git невозможно заставить существующие клоны удалить файл из их соответствующих историй.

Вы можете очистить одну ветку и сделать ее основой для будущей разработки:

$ git checkout -b old-master master
$ git filter-branch ... master

Теперь вам нужно отправить продезинфицированный мастер в новое репо, содержащее только чистый мастер:

$ git push new-central master

В существующие репозитории можно добавить новый удаленный и git cherry-pick переходит со своих старых веток на новый чистый мастер, если это необходимо.

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

person Greg Bacon    schedule 01.02.2010

arrow_upward
9
arrow_downward

Просто измените пароль для вашей внутренней базы данных и любой другой службы с таким же паролем. (и то же самое для любого другого пароля, который существовал где-то в вашей истории).

person hasen    schedule 02.02.2010
comment
Любопытно, что я забыл проголосовать за этот ответ. В нашем частном случае это было неприменимо, но в общем случае это путь к широко распространенному репозиторию, и я даже сделал это однажды, когда опубликовал свой любимый проект. (Кажется, в будущем мне следует перепроверить, что я совершаю...) - person Boldewyn; 18.04.2012

arrow_upward
2
arrow_downward

Вы не можете сделать а) без использования rebase или filter-branch. Но я бы сказал, что, наверное, ЛУЧШЕ сделать это сейчас, чем вечно бороться с сокрытием истории. Я думаю, б) можно было бы сделать, разделив историю после фиксации, которая удаляет учетные данные. В результате получится две истории, размещенные в двух разных репозиториях; один перед очисткой и тот, который «перезапускается» сразу после него. История этих двух репозиториев может быть связана через точки прививки в репозиториях. из тех, кому нужно добраться до старой истории.

В любом случае, вам придется иметь дело с целой кучей дерьма, и я бы порекомендовал использовать a) и filter-branch, даже если это требует много работы.

person kusma    schedule 01.02.2010
comment
Извините, что не принял ваш ответ, но ссылка на GitHub в ответе gbacon была на вес золота. - person Boldewyn; 05.02.2010

arrow_upward
1
arrow_downward

Итак, мы закончили, и я хотел бы поделиться, как мы это сделали.

Нам повезло, что в определенный момент ни у кого не было пользовательской ветки. Итак, что мы в основном сделали, так это то, что все в последний раз отправили свои материалы в центральный репозиторий.

Затем мы использовали filter-branch, как описано командой GitHub. У нас тогда был четкий центральный репозиторий.

Наконец (и это сработало только потому, что ни у кого не было локальной ветки, как уже упоминалось) мы удалили наши локальные репозитории и клонировали новые из теперь уже чистого центрального.

В двух словах: Таким образом, это была довольно быстрая и безболезненная процедура. Не элегантно, но сработало.

person Boldewyn    schedule 05.02.2010