Рабочий процесс Git Dev to Production
У меня есть два разработчика, работающих в локальной среде и использующих github. У каждого разработчика есть своя собственная ветка, в которую они добавляются и объединяются, а затем извлекаются и сливаются с основной.
dev1 branch local --> dev1 branch remote -->
--> main
dev2 branch local --> dev2 branch remote -->
Сейчас я хочу представить новую удаленную ветку для development/qa. Моя цель здесь состоит в том, что я хочу подключить эту новую ветку development/qa к работающему сайту, который полностью копирует производственную среду и использовать для тестирования qa, прежде чем вытащить ее в основную.
dev1 branch local --> dev1 branch remote -->
qa/dev branch ----> main
dev2 branch local --> dev2 branch remote -->
У меня есть рабочий процесс, который объединяет main с моим рабочим сервером, поэтому в любое время, когда происходит изменение main, он запускается. Я хочу оставить это на месте.
dev1 branch local --> dev1 branch remote -->
qa/dev branch --> main -->live/prod
dev2 branch local --> dev2 branch remote -->
Сейчас меня беспокоит управление извлечением и слиянием из qa/dev в main. Github имеет main в качестве ветки по умолчанию, с которой всегда извлекаются и объединяются, поэтому, когда одна из удаленных веток dev1 или dev2 извлекается и объединяется, Github всегда устанавливает main по умолчанию. Я предпочитаю, чтобы по умолчанию использовалась ветка qa/dev, чтобы не было ошибки.
Есть ли способ добиться этого при сохранении существующей структуры и рабочего процесса?
Ответы 1
На этом рабочем сервере вы можете изменить восходящую ветку для локальной main на origin/qa/dev
# Connect to production server
cd /path/to/repository
git switch main
git fetch
git branch -u origin/qa/dev
Таким образом, git pull в этом репозитории (на рабочем сервере) будет извлекать и объединять origin/qa/dev с main.
@cbirch Хороший вопрос, но qa/dev должен быть защищен, а это значит, что его следует обновлять только через пул реквест, что дает возможность просмотреть и подтвердить, что то, что оно извлекает, является тем, что вы хотите (и заставляет GitHub сравнивать то, что вы хочу с qa/dev)
Я не уверен, что это помогает. Меня больше беспокоит, когда мы используем интерфейс github.com для переноса dev1 или dev2 в qa/dev: по умолчанию Github хочет сравнить/вытащить/объединить с Main (вместо предпочтительной ветки Dev). Итак, если мы не будем осторожны, кто-то может случайно слиться с Main вместо Dev.