Git: Дилемма рабочего процесса - переназначить на совершенно новую ветку? - PullRequest
0 голосов
/ 31 марта 2020

У нас есть настроенная среда, в которой у нас есть 3 ветки, которые автоматически разворачиваются (Develop, Preprod, Master (Prod)). Это многосайтовая среда, в которой репо работают несколько команд.

Наша цель - иметь возможность разрабатывать функции и объединять их в 2 основных рабочих процесса, один для тестирования, а затем другой для получения кода. на производственный сервер через ветку preprod: 1. Pu sh изменения в ветке разработки для тестирования 2. Перемещение в ветку preprod для подготовки производственной среды, затем pu sh среды preprod до производства.

Наша проблема: мы не знаем, с какой ветви запустить запрос функции. Если мы начнем с разработки, когда мы go будем сливаться с Preprod (рабочий процесс № 2), это перенесет в коммит каждый коммит, который не обязательно готов для Preprod. То же самое и в случае, когда мы запускаем функцию с preprod.

Цель: В идеале, мы хотели бы иметь возможность запустить ветку при разработке и объединить ее с первым рабочим процессом для тестирования. Затем, когда он будет готов для объединения со вторым рабочим процессом, выполните некоторую перебазировку, чтобы ветвь теперь начинала с preprod, а не с development. Тем не менее, я не думаю, что это возможно? Исходя из моего понимания перебазирования, все, что вы могли бы сделать, - это просто переместить ветку в качестве отправной точки дальше вверх по ветке разработки, вместо того, чтобы переместить ветку Feature, чтобы теперь начинать с ветки preprod вместо разработки. Это возможно? Или есть какое-то другое решение, которое мы могли бы использовать для достижения того же эффекта, который пропускает наша команда?

1 Ответ

0 голосов
/ 31 марта 2020

Правильный рабочий процесс git сложно. Я бы порекомендовал использовать рабочий процесс, который уже существует и задокументирован. Таким образом, он с большей вероятностью будет работать в реальном сценарии ios и не иметь слишком много ловушек.

Atlassian документирует ряд стандартных альтернатив .

Ваши концепции звучат ближе всего к рабочему процессу gitflow , так что вы можете на это взглянуть. Он содержит много типов веток: master, development, релизы, исправления и функции.

Лично я предпочитаю рабочий процесс ветви feature . На самом деле это проще, чем gitflow, поскольку у него есть только основная ветвь и ветвь функций, но он работает лучше всего, если у вас есть тщательный анализ кода (в запросах на извлечение) и автоматические тесты с хорошим охватом, чтобы вы могли с уверенностью слиться.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...