Git автоматически отправляет в Dev и Production из центрального репозитория в зависимости от отправленной ветки

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

В моей сети есть три сервера: один для разработки (dev.example.com), один для производства (www.example.com) и еще один, выступающий в качестве центрального этапа между ними (central.example.com).

Я хочу создать основной (вероятно, голый) репозиторий Git на Central, который я могу отправить с моей локальной машины (которая отделена от трех основных серверов, но находится в той же сети). В идеале у этого репозитория должно быть две ветки: master и Development. Моя локальная машина будет иметь дело только с этим репо на Central.

Когда я отправляю в ветку dev на Central, Central должен затем отправить эти изменения на сервер DEV. Точно так же изменения в главной ветке должны быть отправлены в WWW. Я думаю, что использование хука фиксации/обновления было бы лучшим способом сделать это.

Вот грубо нарисованная схема:

 Local
   |
 Central
  /   \
DEV   WWW

Может ли кто-нибудь указать мне правильное направление? Спасибо!


git production staging
person Blu Dragon    schedule 22.04.2011    source источник
comment
Я наткнулся на этот хук, который, похоже, позволит мне выполнить отправку в не голый репозиторий или другими словами, корень документа как WWW, так и DEV. Есть возражения?   -  person Blu Dragon    schedule 22.04.2011
comment
Этот пост: blog.ekynoxe.com/2011/10/22/ очень хорошо объясняет   -  person tver3305    schedule 07.08.2012

Ответы (2)


arrow_upward
3
arrow_downward

Вы должны использовать хук post-update или post-receive; это те, которые запускаются после завершения отправки в репозиторий. Единственная разница между ними заключается в том, как они получают аргументы.

Чем я бы предложил использовать триггер ssh для производственного/промежуточного сервера, чтобы запустить оттуда, потому что:

  • Вам все равно нужно запустить какой-то код там, потому что push in git не поддерживает проверку отправленной версии на удаленном конце. Так что вам понадобится еще один крючок там.
  • Запуск push туда означает разрешение push-доступа туда, а это означает еще одну вещь для защиты. С другой стороны, триггер ssh будет иметь жестко запрограммированную ветку для извлечения, поэтому никто не может причинить ему никакого вреда, если только центральный репозиторий также не скомпрометирован, и, что более важно, даже если это так, потенциальный вред ограничивается только обманом для получения плохой версии. , но никакие данные не могут быть удалены и доступ к остальной части компьютера не может быть получен.

Триггер ssh — это сценарий, связанный с определенным открытым ключом в ssh (префикс открытого ключа в .ssh/authorized_keys с префиксом command=триггер). Когда вы входите в систему с помощью ssh, используя этот ключ, ssh проигнорирует команду, предоставленную клиентом, и запустит триггер. Это ограничивает возможный ущерб, когда кто-то крадет ключ, потому что триггер может использовать свою собственную логику, чтобы знать, что делать, и не принимать никаких входных данных от клиента.

В качестве альтернативы вы можете просто нажать и установить соответствующий крючок, чтобы проверить. См. этот вопрос < /а>.

person Jan Hudec    schedule 22.04.2011

arrow_upward
2
arrow_downward

Вы можете настроить хуки в Git, чтобы легко получить то, что вы хотите здесь. Используйте хук post-receive, который получает от стандартного ввода следующее:

<oldrev> <newrev> <refname>

Пример:

aa453216d1b3e49e7f6f98441fa56946ddcd6a20 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master

Используя refname, вы можете увидеть в своем скрипте, какая ветка отправляется, и, в свою очередь, нажать на соответствующий репо - www или dev.

Или вы можете использовать хук post-update, который получает только refname, а также в качестве аргумента, чтобы сделать то же самое.

Для полноты хук нужно поместить в хуки центрального репо.

person manojlds    schedule 22.04.2011