Разветвление Git в тестовой среде

Question

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

Рабочий процесс команды во многом отличается от обычного git. Ветви

Local (feature/hotfix branch from Dev) -> Dev -> Test -> Prod

Среды

Dev -> Test -> Prod

1. Каждая ветвь имеет разные конфигурационные файлы (пока нет решения. Но сначала я исправлю эту проблему), поэтому мы не можем объединить ветки.
2. Разработчики работают над Local (ветка feature / hotfix) и объединяют свои изменения в ветку Dev и публикуют свои версии в среде Dev (просто увеличивается версия патча (1.0.xxx), я знаю, что это не очень хорошая вещь).
3. И затем они черпают свои изменения в ветке Test. И они публикуют новую версию в тестовой среде. UAT здесь радует
4. Когда разработчики хотят опубликовать свои изменения в производственной среде, они также выбирают их. И опубликовать новую версию в среде prod.

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

Вторая проблема - некоторые изменения должны оставаться в тестовой среде 1-2 недели, изменения могут иметь длительный или короткий срок службы.

Третья проблема, мы не можем использовать такие функции git, как слияние и запрос на извлечение. Мы хотим использовать PR для проверки кода и так далее. Это важно для нас.

Я могу сказать, что процесс развертывания и система контроля версий смешаны в этом сценарии. Поэтому мы хотели бы использовать что-то вроде git-flow. Хотя мы хотим сохранить эти три среды (dev, test и prod) и основной целью является объединение ветвей и использование запросов извлечения.

Допустим, у нас есть только развивающие и осваивающие отрасли. Разработчики работают над тематическими ветками. И объединить их функции в разработке. Далее мы создали ветку релиза для тестовой среды. Но что мы должны делать для разных наборов изменений времени жизни?

Как мы должны объединить ветки релиза в главную ветку? Как нам обращаться с тестовой средой на ветках git?

Например;

release 1.3.0 - иметь функцию, которая должна оставаться в тестовой среде 2 недели, а затем переходить в производственную среду

release 1.4.0 - кто-то добавил новую функцию, которая должна появиться в производственной среде через пару дней. (в то время как release 1.3.0 все еще жив.)

Таким образом, тестовая среда будет иметь две последние функции, а prod должен иметь самую последнюю через пару дней. Но release 1.4.0 Филиал имеет обе функции. Что мне слить в производственную отрасль?

Должны ли мы использовать что-то другое, чем git-flow? какова ваша рекомендация?

Answer 1

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

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

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

Скажите, что у вас есть файл конфигурации config.json в Dev и один с другим содержанием в Test,

Вы можете сделать это

# register a merge driver named 'ours' that uses the command 'true' to always return 0
git config --global merge.ours.driver true

git checkout Dev
echo 'config.json merge=ours' >> .gitattributes
git add .gitattributes
git commit -m 'Preserve config.json during merges'

git checkout Test
# copy the same commit, since we want the same setting in all branches
git cherry-pick Dev

# now, when you merge, config.json will be ignored
git merge Dev

Полный пример здесь

Таким образом, это должно позволить объединить ветви, что должно решить вашу первую и вторую проблему. Добавление PR к этому также должно работать, решая вашу третью проблему.