2017-01-29 11 views
-2

Вопрос о том, как практически использовать Git.Рекомендации по использованию Git для хранения файлов из двух разных сред

У меня есть код, который развернут на 2 сервера (1 для постановки, 1 для производства); это тот же код, но для нескольких файлов (разные пути в файлах конфигурации).

ПРИМЕЧАНИЕ. Обычно я совершаю/удаляю из ноутбука dev и просто вытягиваю с этих двух серверов.

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

Хотя, я не знаю точно, где поставить и переформатирование для промежуточного сервера:

  • ли лучше использовать промежуточную ветвь? Но тогда я должен подумать, что каждый раз, когда я вношу изменения в мастер-ветку, я должен ремистировать.

  • Лучше совершать локально, на промежуточном сервере, путь изменяется, и пусть Git переустанавливает эти фиксации (поверх HEAD) каждый раз? Но, потом, у меня есть unpushed фиксаций пребывающих там - это может стать немного беспорядка, и я не толкать их по ошибке ...

Есть другой, более простой, сценарий, который я дон Думаешь?

+0

Это не совсем понятно, о чем вы спрашиваете. –

+0

Файлы на 99% идентичны как в env (stg, prd). Что мне делать для 1% разницы? Поместите версию для среды stg на другую ветку? Поместите его как фиксацию, которая хранится локально на сервере stg (и будет переустанавливаться каждый раз, когда я вывожу новые изменения из репо)? Или лучше использовать другую «модель»? – user3341592

+0

Является ли это более ясным сейчас? – user3341592

ответ

2

Для этого следует использовать переменную окружения. Вы можете определить переменную окружения для выбора между постановкой и производством. Если он не определен, вы можете использовать его по умолчанию.

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

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

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

+0

Я правильно понимаю, что вы говорите о переменных оболочки env, например? Потому что мои отличия затрагивают больше, чем это: а также пути или некоторые небольшие функциональные возможности в ASP-страницах и README-документы ... Поэтому я не могу суммировать все как условие в зависимости от имени хоста. – user3341592

+0

Я думаю, что комментарий, данный @destrif, имеет смысл тогда. http://stackoverflow.com/questions/9636492/branching-different-config-files-for-release-development. Вы можете добавить .gitattributes и фильтр smudge, как описано в этой ссылке – manishg

+0

Да, это лучший способ справиться с этим. Мне совершенно неизвестно. Рад, что я снова узнал что-то новое ... – user3341592

0

Это лучше управлять этими конфигурационными файлами в виде отдельных файлов:

  • myconfig.master
  • myconfig.dev
  • ...

Тогда, как я описал в "Ignore files when merging branches", вы можете объявить content filter driver (с использованием .gitattributes declaration), который, при проверке, автоматически скопирует нужный файл как myconfig.
Текущий файл myconfig будет игнорироваться и закрыт.

smudge

Ваш smudge сценарий может определить имя извлечённой ветви с:

branch=$(git rev-parse --symbolic --abbrev-ref HEAD) 

 Смежные вопросы

  • Нет связанных вопросов^_^