Рекомендуемый рабочий процесс git для тестовых и производственных экземпляров

Question

Хотя я уже некоторое время использую git, я все еще считаю себя n00b, поэтому, пожалуйста, не будьте слишком резкими со мной.

Я поддерживаю "корпоративную" систему мэйнфреймов, так какдве неидентичные копии.Давайте назовем их Test and Production.В мэйнфрейме нет ничего, что я (или, возможно, любой из вас) мог бы считать системой контроля версий, поэтому я использую git на рабочем столе для обеспечения контроля версий.Вот основные особенности моего текущего рабочего процесса:

• Рабочий стол и мэйнфрейм "синхронизированы" с FTP.В конце концов, все работы по разработке, написанные на мэйнфрейме или на ПК, заканчиваются на ПК в ветке git.

• У меня нет доступа к какому-либо «современному»Технология развертывания, такая как Hudson

• У меня есть две основные ветви, называемые Test и Prod.Из-за (унаследованной) структуры продукта существует ряд различий в коде между экземплярами Test и Prod.Например, все панели дисплея должны четко определять, является ли это Test или Prod, но нет способа настроить это в одной точке.

• Обычно я создаю другие ветви,Специально для конкретных подпроектов разработки.

• Общая разработка выполняется в ветке Test с несколькими коммитами.Когда все готово, они выбираются в Prod, помечаются номером изменения и загружаются после утверждения.

• Аварийные работы, к счастью, редкие, выполняются на ветке Prod и собираются в тесте.

• Сбор вишни очень редко, требует ручного слияния.

Я хотел бы улучшить этот рабочий процесс.В настоящее время мой репозиторий полон параллельных идентичных изменений в двух ветвях.

Я думаю, что предпочел бы сделать это следующим образом (для Test -> Prod):

• Как только разработка будет готова, создайте новую ветку в HEAD of Prod

• Свернуть этот набор изменений развития в одно изменение в новой ветви

• Объединить эту новую ветку с Prod.Имейте в виду, что их общим предком является до изменений, которые делают Test отличным от Prod

Кажется, что git rebase -i может сделать эту работу, но я должен признатьсячто git rebase - это мои pons asinorum , и каким-то образом мне удалось несколько раз испортить мое дерево.

Итак, мои вопросы таковы:

1. Пожалуйста, предложите лучший способ, в пределах ограничений продукта.

2. Если мой предпочтительный подход жизнеспособен, может кто-нибудь предложить правильные параметры для git rebase -i?

Answer 1

Что касается различий между Test и Prod, проверьте, можете ли вы обнаружить, находитесь ли вы в той или иной среде.

Это позволит изменять файлы с содержимым платформы при извлечении с помощью драйвер фильтра через нечеткий сценарий.

Таким образом, вам не придется поддерживать ветки просто для разделения на почти идентичные наборы кода.

Answer 2

Моя рекомендация состоит в том, чтобы объединять ваши ветки разработки (Test) и Production (Prod) друг с другом чаще, чем чередовать изменения. В частности, по мере внесения изменений в Prod их часто (не реже одного раза в день) объединяют в Test. Когда изменения в Test готовы, объедините их с Prod.

То, что вы выбираете коммиты из Test to Prod после одобрения, также предполагает, что ваши коммиты плохо разделены и вместо этого представляют собой несколько коммитов с очень большими разностями каждый. Это затрудняет использование вашей истории для отладки проблем и делает практически невозможным возврат одного изменения (путем возврата одного изменения).

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