Git: Удалить учетные данные из хранилища - PullRequest
8 голосов
/ 01 февраля 2010

Сначала: это (надеюсь) не дубликат этого или этого .

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

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

Вопрос: Что было бы хорошей стратегией для

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

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

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

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

Ответы [ 4 ]

9 голосов
/ 01 февраля 2010

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

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

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

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

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

$ git push new-central master

Существующие репозитории могут добавлять новых удаленных и git cherry-pick изменений из своих старых ветвей в новый чистый мастер при необходимости.

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

7 голосов
/ 02 февраля 2010

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

2 голосов
/ 01 февраля 2010

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

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

1 голос
/ 05 февраля 2010

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

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

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

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

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

...