Мерзавец: Удалите учетные данные из репозитория
Сначала: Это не (надо надеяться), никакой дубликат этого или этого.
Текущий статус: Я фиксировал файл с учетными данными для внутренней базы данных в мой репозиторий Мерзавца. Это было прекрасно, когда я использовал его только один. Затем моя группа начала клонировать, продвигать и вытягивать вокруг в этом проекте. У нас теперь есть несколько репозиториев Мерзавца (одно центральное и некоторые разработчики).
Проблема: Мы теперь хотим предоставить открытый доступ к исходному коду, и к репозиторию Мерзавца или по крайней мере позволить Мерзавцу управлять деталями других, способствующих коду.
Вопрос: К чему была бы хорошая стратегия
a) удалите файл с учетными данными от центрального или из всех репозиториев, или
b) откройте новый репозиторий Мерзавца как вид 'интерфейса' к внешнему миру?
При выборе (b), как мог, мы легко связываемся, возвращается в основной репозиторий?
Из-за уже широко распространенного распределения, мы действительно хотели бы не сделать a git rebase или a git filter-branch на каждом текущем репозитории.
4 ответа
Извините, но вы застряли с запуском git-фильтра , если хотите удалить учетные данные из главного репозитория. См. раздел Удаление конфиденциальных данных, написанное людьми из GitHub.
Из-за дизайна git'а не существует способа заставить существующих клонов удалить файл из их соответствующей истории.
Вы можете дезинфицировать одну ветку и сделать её основой для будущего развития:
$ git checkout -b old-master master
$ git filter-branch ... master
Теперь вам нужно будет подтолкнуть дезинфицированного мастера к новому репо, содержащему только чистого мастера:
$ git push new-central master
Существующий репозиторий может добавлять новые удалённые и вишнёвые изменения из старых ветвей к новому чистому мастеру, если это необходимо.
Для нового репозитория установите какой-нибудь барьер, чтобы предотвратить перемещение в него конфиденциальных данных, чтобы у вас не возникало снова и снова одной и той же проблемы. Этот барьер может быть человеком, который контролирует новый центральный репозиторий и просматривает все патчи, чтобы решить, что входит.
Просто измените пароль для своей внутренней базы данных и любой другой службы с таким же паролем. (и то же самое для любого другого пароля, который существовал где-то в вашей истории).
Невозможно сделать а) без использования rebase или filter-branch. Но я бы сказал, что, наверное, ЛУЧШЕ сделать это сейчас, чем вечно бороться с сокрытием истории. Я предполагаю, что б) можно сделать, разделив историю после фиксации, которая удаляет учетные данные. В результате получились бы две истории, помещенные в два разных репозитория; один перед очисткой, а другой "перезапускается" сразу после него. История этих двух репозиториев может быть связана через точки привязки в репозиториях тех, кому нужно добраться до старой истории.
В любом случае, вам придется иметь дело с целой кучей дерьма, и я бы рекомендовал использовать a) и filter-branch, даже если это большая работа.
Итак, мы закончили, и я хотел бы рассказать, как мы наконец это сделали.
Нам повезло, что ни у кого в определенный момент не было собственной ветки. Итак, что мы в основном сделали, так это то, что все в последний раз отправили свои материалы в центральный репозиторий.
Затем мы использовали filter-branch , как описано на нем командой GitHub. Тогда у нас было четкое центральное хранилище.
Наконец (и это сработало только потому, что ни у кого не было локальной ветки, как упоминалось) мы удалили наши локальные репозитории и клонировали новые из теперь чистого центрального.
Короче говоря: таким образом, это была довольно быстрая и безболезненная процедура. Не изящно, но сработало.