Использование контроля исходного кода GIT в среде веб-разработки

Question

В настоящее время я использую GIT с исходным деревом для управления моим исходным кодом для веб-системы php.

Мой предыдущий опыт работы с GIT не связан с веб-средой, и я понимаю использование филиалов и удаленных устройств и т. Д.

Но я немного запутался, когда дело доходит до настройки этогодля веб-разработки.

Сценарий.

У меня есть живой поддомен
live.mysite.com

У меня есть поддомен dev
dev.mysite.com

Я создаю ветки на сайте разработчиков для историй.Оформить заказ сотрудникам ветки истории с сайта разработчика, завершить и зафиксировать.Затем каждая история проверяется тестером и тестируется, после завершения история объединяется с мастером разработки, и в конечном итоге она объединяется с живой.

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

Чтобы обойти это, я создал поддомен для каждого сотрудника.

rob.mysite.com

dave.mysite.com

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

вносить изменения на rob.mysite.com push rob в dev push dev dev чтобы жить и т. д.

Хотя этот вид работ, я чувствую, что это не правильно.

Это почтинарушает всю точку ветвления, поскольку весь персонал будет оттуда ветвиться из собственного репозитория.

Это правильно, и мне всего несколько шагов или я полностью отключен?

Answer 1

Прежде всего, похоже, что сотрудникам нужна локальная среда разработки.Разработчики не должны нажимать какие-либо изменения, чтобы проверить их.Это сильно замедляет разработку.

Общий рабочий процесс может выглядеть следующим образом:

1. Выбор историй для работы.
2. Развивайте свою функцию.
   1. При необходимости создайте для него ветку, основанную на основной ветке или ветви разработки.Так называемая функциональная ветвь.Технически, если разработчик принимает локальные коммиты, это уже ветвь.
   2. По желанию, вносите изменения в удаленную копию ветви функций, когда вы хотите создать резервную копию своей работы.
3. Проверьте, работают ли ваши изменения в локальной среде разработки, и запустите тесты.
4. Если тесты зеленого цвета, объедините ветвь функций в ветку master / development.
5. Разверните master / developmentв промежуточную среду и попросите тестировщиков протестировать ее.
6. Если тесты хороши, объедините мастер в живую и разверните в живую.

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

Я хотел бы порекомендовать больше узнать о Непрерывная интеграция и Непрерывная доставка .