Как обработать файл в git?

Question

Например, banne.gif, config_mysql.php.
banner.gif необходимо при кодировании, потому что нам нужно проверять компоновку CSS, и дизайнер всегда меняет ее.
config_mysql.php необходимо при кодировании, потому что мынужен этот файл для запуска mysql, и мы не можем использовать production version.

Я не уверен, что git add эти файлы или поместить эти файлы в .gitignore.
Каков наилучший способ обработки таких файлов в git?

Answer 1

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

Файлы изображений

Если они маленькие и / или не часто меняются,Вы можете просто подумать о них и не беспокоиться об этом.Хотя git не как хорошо справляется с обработкой бинарных файлов, главная проблема, которую они вызывают, - вздутие хранилища;и при умеренных размерах это не большая проблема.

Для целей, которые вы описываете, вы можете уменьшить размер (и, возможно, частоту изменений), используя заполнители с правильными размерами.

Если изображениефайлы могут стать проблемой, вы можете использовать инструмент, подобный git lfs, который держит размер репо под контролем, предоставляя вторичное репо для файлов, таких как большие двоичные файлы.

Файлы, специфичные для среды

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

Answer 2

На мой взгляд, у вас может быть две версии banner.gif и config_mysql.php.

Например, вы можете зарегистрироваться, чтобы Git эти файлы: config_mysql.php и config_mysql_dev.php

На производстве используйте config_mysql.php файл.

И на своем локальном компьютере вы можете переименовать файл config_mysql_dev.php в config_mysql.php, чтобы использовать его.

Можно подумать о похожих вещахдля banner.gif ...

Answer 3

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

Решение 1: Примерфайлы

Вместо того, чтобы хранить config_mysql.php внутри репозитория, сохраните файл с именем config_mysql.php.sample и добавьте config_mysql.php к .gitignore

Люди, которые клонируют или разветвляются от мастера локально, могут затем указать ихзначения свойств config_mysql.php, которые добавляются к .gitignore и, таким образом, не влияют на дерево мерзавцев.Разработчик редактирует файл config_mysql.php.sample только в том случае, если конфигурация добавлена ​​/ удалена (это информация, которую необходимо добавить в репозиторий исходного кода)

Решение 2. Сохраните значения конфигурации в переменных среды

Вместо указания фактических значений для ключей в config_mysql.php.sample извлеките их из переменных среды.

$db_host = $_SERVER["MYAPP_DB_HOST"];
$db_user = $_SERVER["MYAPP_DB_USER"];
// and so on

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

Резюме

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