Развертывание веток git

Question

После того, как я боролся с рабочим процессом для веб-разработки и разбирался с ним с помощью git, мне было поручено добавить промежуточный сервер в последнюю секунду. Мы разрабатываем / тестируем локально и отправляем в репозиторий, и теперь между ними должна быть песочница, чтобы люди в других отделах могли поиграть и попробовать что-то новое, не ломая вещи.

Для удаленного репо нужны две продолжительные ветви (в духе модели ветвления nvie), освоить и развить.

Нам нужно иметь возможность перейти к одному репо и оформить ветку разработки для документирования test.site.com, а когда будет готово, объединить разработку в мастер и оформить заказ в документ site.com

Так на сервере ...

git init
git add .
git commit -m "Initial commit"
git checkout -b "develop"

А на наших локальных машинах ...

git clone user@site.com:/repos/repo1.git
???
git push origin/develop (??? Updates test.site.com docroot)

И обратно на сервер, чтобы сделать код живым

git checkout "master"
git merge develop (??? Updates site.com docroot)
git checkout -b "develop"

И локально

git pull

Помощь с вопросительными знаками или альтернативные предложения приветствуются.

Edit: Пока экспериментирую с некоторыми ответами. В тот момент я придумал совершенно хакерскую идею и подумал, что я поделюсь:

Один хук после получения, чтобы управлять ими всеми.

Мы клонируем голое репо и разрабатываем трек. Толчок развиваться к возникновению / развитию.

Пост-получение - установите GIT_WORK_TREE на test.site.com, оформить заказ -f развернуть

Если сообщение фиксации содержит «merge_master», для GIT_WORK_TREE присваивается значение site.com docroot,

git checkout master
git merge develop  
git checkout -f master (this would be for hotfixes)

Объединить мастера обратно в разработку и локально потянуть

После того, как пыль осядет, отправьте электронное письмо с difflog, скрутите руки и сделайте глоток чего-нибудь крепкого.

Сколько разных способов это может сломаться?

Answer 1

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

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

Теперь у вас есть веб-серверы. Они могут быть либо рабочими копиями, либо просто экспортированными, созданными с использованием git archive, и могут быть обновлены с помощью cron или post-update hook в центральном хранилище.

Рабочая копия обновляется git fetch central-repo-url master на site.com сервере и git pull central-repo-url develop на test.site.com сервере (хорошо, выборка + сброс, предложенные в другом ответе, вероятно, лучше, потому что вы уверены, что нет есть какие-то изменения).

Экспорт обновляется путем получения пакета zip или tar с git archive и его распаковки. Это немного больше работы.

Крон просто периодически запускает команды. Это проще в настройке, но недостатком является задержка между отправкой и отображением контента на серверах.

Хук

post-update более сложен в настройке, но не имеет этой задержки (очевидно, есть некоторая задержка, так как загрузка данных тоже занимает некоторое время). По сути, вы создаете скрипт для запуска обновления, который может быть запущен с помощью ssh или веб-запроса на серверах. Чем в центральном репозитории вы положили скрипт hooks/post-update, который будет запускать скрипты на серверах. Не должно быть никакого способа дать им какие-либо параметры, и механизм не должен позволять запускать любой другой код, кроме этих сценариев, из соображений безопасности. Вы можете сделать ловушку более продвинутой, посмотрев, какая ветвь была нажата (см. Git doc, где вы ее нашли) и запустив только правильный сервер.

Чем git push origin develop приведет к обновлению test.site.com (но косвенно, через скрипты) и выполнению кода, который вы будете делать (на компьютере разработчика; никогда не работает на сервере!)

мастер проверки git мерзавец слияния развиваться git push origin master

и последняя команда приведет к обновлению site.com, опять же косвенно через сценарии.

Answer 2

Я предлагаю сделать так, чтобы оба документа были рабочими копиями.

После этого у вас есть два варианта

1. Попросите cron сделать что-то вроде git fetch development-repo; git reset --hard development-repo/branch для обоих. Я делал подобные вещи раньше, и обязательный сброс - обязательный: он уничтожит все случайные изменения, которые каким-то образом проникли в ваш докут.
2. Имейте хук post-update в репозитории разработчиков, делайте это каждый раз, когда кто-то что-то толкает. К сожалению, у меня нет рабочего примера этого под рукой.