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

Question

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

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

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

Так что на сервере...

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

И на наших местных машинах...

git clone [e-mail]:/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

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

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

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

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

Post-receive - установить 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 крючок в центральном хранилище.

Рабочая копия обновляется 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 checkout мастер git merge разработать мастер оригинального git push

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

Answer 2

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

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

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