Разветвление Git в тестовой среде - PullRequest
Новая
       87

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

0 голосов
/ 11 февраля 2019

Я начал работать в компании, которая недавно использовала 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) и основной целью является объединение веток и использование запросов на извлечение

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

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

Например;

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

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

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

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

1 Ответ

0 голосов
/ 12 февраля 2019

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

Ваш существующий рабочий процесс звучит под влиянием чего-то вроде подрывной деятельности, где обычно избегают слияния, вместо этого выбирая вишню.В 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 к этому также должно работать, решая вашу третью проблему.

...