Как мне иметь три варианта веб-сайта (с их каталогами развертывания) в виде веток в одном репозитории вместо трех разных?

Question

Я использую Git для развертывания веб-сайта с тремя разными доменами на двух разных серверах, каждый из которых представляет разные фазы разработки: dev, staging и production

Я успешно настроил развертывание, используя каждый веб-корень в качестве удаленного репозитория и используя ловушку пост-получения, чтобы обновить себя по запросу.

Но есть несколько проблем с этим. Во-первых, когда другой разработчик вносит изменения, я хотел бы знать, что мне нужно только удалить из одного репозитория. Я не хочу спрашивать его, к какому из 3 он привержен. Во-вторых, было бы неплохо воспользоваться некоторыми ветвлениями, чтобы не только каждый этап веб-сайта имел свое собственное репо, но и собственный филиал, чтобы локально каждая из моих веток «dev», «постановка» и «вживую» подтолкнет к правильному репо.

Это моя мечта. Может кто-нибудь придумать, как выполнить этот рабочий процесс? Я с треском провалился.

Answer 1

Вы могли бы сделать что-то вроде этого. В этом рабочем процессе я предполагаю, что центральный сервер (origin>), ваш компьютер (local>) и некоторые devolopers (deva>, devb>).

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

local>git checkout -b dev
local>git push -u origin dev
local>git checkout -b staging
local>git push -u origin staging
local>git checkout -b live
local>git push -u origin live

Ok.

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

devx>git fetch
devx>git checkout --track origin/dev
devx>git checkout --track origin/staging
devx>git checkout --track origin/live

Итак, допустим, что Дева выполнила некоторую работу, на которую вы хотите взглянуть. Мы предполагаем, что он / она работает над новой функцией в ветке dev.

deva>git checkout dev
deva> ... edit some files
deva>git commit -am "new feature bla bla"
deva>git push

Вы получаете письмо от Девы, что он отправил свои изменения. Тогда вы делаете:

local>git checkout dev
local>git pull

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

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

Надеюсь, это помогло вам осуществить свою мечту: D

Answer 2

Еще одно предложение, которое я хотел бы сделать, это Gitflow, соответствующие ссылки

http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

https://github.com/nvie/gitflow

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

Answer 3

Вам нужно защитить репо с помощью какого-то механизма, чтобы разработчик не смог:

• толчок к неправильному репо,
• подтолкнуть неправильную ветку к неправильной удаленной ветке

Это тип инкапсуляции Гитолит может обеспечить.

Другим способом является предотвращение каких-либо операций с некоторыми репозиториями для определенных людей, что будет соответствовать рекомендациям Линуса в его презентации Google в 2007 году :

Одна вещь для коммерческих компаний: распределенная модель также помогает в процессе выпуска.
У вас может быть команда проверки, которая имеет свое собственное дерево. И они получают от людей, и они проверяют это, и они проверяют это, они могут передать это команде релиза и сказать: «Эй. Мы уже проверили нашу версию», и люди, занимающиеся разработкой, они могут продолжить, играя со голову, вместо того, чтобы создавать теги, ветви, что бы вы ни делали, чтобы не мешать друг другу.
Опять же, вы держите друг друга в стороне, так как каждая отдельная группа может иметь свое собственное дерево и отслеживать свою работу и то, что они хотят сделать.

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

Answer 4

Используя метод из http://toroid.org/ams/git-website-howto в качестве отправной точки, вы можете изменить ловушку после получения, чтобы оформить заказ на определенную ветку.Для нескольких сайтов на одном сервере вы можете попробовать добавить еще одну строку git checkout, чтобы каждый сайт обновлялся из соответствующих ветвей при каждом запуске ловушки.На этой странице также рассказывается о том, как настроить локальное git-репо для отправки более чем в один репозиторий с помощью одной команды.