Когда я вытягиваю из github в хранилище сервера, я хочу избежать перезаписи локализованной конфиденциальной информации в определенных файлах, например config.php.

Примечание: это не репо с открытым исходным кодом; У меня есть полный контроль над хранилищем, я единственный пользователь, это личное, но очень важно,он основан на среде с открытым исходным кодом, которая может изменить структуру файлов конфигурации, Я просто хочу иметь возможность извлекать из него данные для тестирования, подготовки и производства, и не случайно запускать производственный конфигурационный файл на тестирование и т. Д. Но я не могу перекодировать файлы конфигурации для извлечения данных из другого источника без необходимости тяжелые ситуации слияния позже, если инфраструктура будет обновлена.

в идеале Я бы хотел сказать Git, что при извлечении во время выборки из REPO_URI всегда отбрасывать любые фрагменты, которые могли бы изменить информацию, которая в настоящее время находится в строке 24 FILE_PATH. Однако я понимаю, что это невозможно (поправьте меня, если я ошибаюсь).

тем не мение если кто-то не может предложить способ сделать это, пожалуйста, прочитайте приведенное ниже решение и дайте мне знать, если это кажется идеальным способом сделать это:

Я бы использовал расширение ключевых словкак описано в руководстве пользователя Git здесь, Ниже я опишу, как я это сделаю, а затем внизу задаю несколько вопросов об этом подходе.

Описание метода

Сначала я бы написал два скрипта, «Sensual_values_inserter» и «Sensual_values_remover», которые меняют некоторые фиктивные ключевые слова (которые будут в мастере репозитория github) с конкретной конфиденциальной информацией, такой как пароли, имена пользователей, пути к базам данных и т. Д .:

#! /bin/sh -f
sed -e 's/@USERNAME@/dummyvalue/' -e 's/@PASSWORD@/dummyvalue/' $1

и т.п.

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

/live/filters/sensitive_values_inserter
/live/filters/sensitive_values_remover
/live/repo/{LIVE}
/test/filters/sensitive_values_inserter
/test/filters/sensitive_values_remover
/test/repo/{TEST}
/stag/filters/sensitive_values_inserter
/stag/filters/sensitive_values_remover
/stag/repo/{STAG}

Каждый из этих фильтров будет иметь конкретные значения для соответствующих настроек.

Тогда конфигурация всего репо будет изменена следующим образом:

$ git config filter.infosafe.smudge '../filters/sensitive_values_inserter'
$ git config filter.infosafe.clean '../filters/sensitive_values_remover'

Наконец, в репозитории сервера сделайте это:

$ echo 'config.php filter=infosafe' >> .gitattributes

Таким образом, всякий раз при извлечении из основного сервера, если я правильно понимаю, эти фильтры заменят «фиктивные» значения теми, которые я хочу использовать.

Замечания: чтобы заставить это работать, как указано вэтот другой вопрос stackoverflowпосле настройки, как указано выше, вы должны:

cd /path/to/your/repo
git stash save
git checkout HEAD -- "$(git rev-parse --show-toplevel)"
git stash pop

В промежутке между извлечением и копированием я должен был зафиксировать все изменения в файлах, где выполнялась чистая операция. Не волнуйтесь, после того, как вы их передадите, те в рабочем каталоге испачкаются. (Это немного нелогично, но работает.)

Мне удалось успешно нажать на github, и появляются только чистые значения.

(Существует альтернативный, более продвинутый метод в этом направлении, который включает в себя использование одного .gitignore на ветвь и двух драйверов и двух фильтров на ветвь. Это позволяет удалять действующие пароли при переключении на тестовую ветвь и наоборот. Хитрость заключается в том, чтобы вызывать очистители для обеих ветвей в .gitignore каждой ветви, но вызывать только smudger ветви, которая является домом .gitignore, поэтому он восстанавливает сам пароль. Тем не менее в этом сценарии при нажатии на GitHub вся конфиденциальная информация остается очищенной, и это хорошо. Я могу подробно рассказать об этом, если кому-то будет интересно.)

Вопросы об этом методе и альтернативах

Я проверил это, и это работает. Но...

Есть лучший способ сделать этоиспользуя мерзавец? Я мог бы добавить, что нельзя игнорировать файлы, содержащие конфиденциальную информацию, и нельзя игнорировать изменения при слиянии, потому что я хочу иметь возможность извлекать изменения в эти файлы, сохраняя определенные значения конфигурации , Вот почему я не хочу просто использоватьgit update-index --assume-unchanged FILENAME навсегда игнорировать будущие локальные изменения целых файлов.

Благодарю.