Правильная процедура объединения веток проекта в демонстрационную ветку - PullRequest
Новая
       16

Правильная процедура объединения веток проекта в демонстрационную ветку

0 голосов
/ 20 мая 2019

График ниже представляет желаемый поток для того, как я хочу, чтобы наша среда разработки продолжалась.Существует 4 стандартных филиала: ProdMaster, TestMaster, DevMaster и master.Предполагая, что вышеперечисленные четыре исходят из одной и той же базовой линии, каждый из трех разных разработчиков может создать новый проект или ветвь функции вне основного.После завершения разработки каждый из них объединит свои изменения в DevMaster.Dev в основном предназначен для демонстрации и тестирования, поэтому допустим, что ветка Project \ Feature 2 одобрена для тестирования, а 1 и 3 - нет.Я хочу иметь возможность затем взять ветку проекта 2 и объединить ее в тест без каких-либо изменений, которые произошли в ветвях проекта 1 и 3.

Изначально мы использовали Merge Commits в GitHub, но чтомы заметили, что если объединить ветку Project 1, то 2 и 3, вторая ветвь получит коммиты из первой ветки, а третья получит коммиты от 2 и 3.

Итак, мы попытались сделатьsquash and merge, и это, похоже, сработало, так как новые ветки project \ feature не заражались отдельными коммитами из базовой ветки.В основном это работает, за исключением одного незначительного изменения, которое иногда отображает все изменения, уже внесенные в базовую ветку.Иногда это происходит из-за конфликтов, и если я исправляю конфликт в одном файле, количество изменений файлов возрастает с 130+ до 1. Это перебазировка, которую я должен использовать?Смесь двух?Или у меня просто неправильный поток?Я исследовал довольно много, как и другие члены моей команды, и трудно увидеть практическую разницу между сквошом и ребазом, даже когда он взят в графическом виде.

Git flow

1 Ответ

0 голосов
/ 20 мая 2019

Это возможный поток разработки, и да, вы ищете ребаз.

Вы можете взять одобренную ветвь PB2 и перенести ее на TestMaster (при условии, что здесь и TestMaster, и master тесно связаны).

При желании вы можете объединить все изменения в один коммит.

Примечание 1: после того, как ветви PB1, PB2, PB3 объединены в DevMaster, они «спаяны» и не должны быть «объединены». Вы можете использовать DevMaster для массового тестирования, но вы должны использовать исходную ветку PB2 для TestMaster, если это ваша единица утверждения, или полностью отклонить все 3 изменения. Может быть, поэтому у вас путаница?

Примечание 2: в вашем описании я не вижу разницы между "master" и "TestMaster", потому что по сути обе ветки должны содержать утвержденные изменения, готовые для тестирования.

Альтернативный подход

У вас есть 4 этапа в процессе:

  1. развивается в ветви функций
  2. тестирование для утверждения на DevMaster
  3. тестирование на TestMaster
  4. в ожидании релиза на ProdMaster

Таким образом, вместо фиксированных веток, таких как DevMaster, TestMaster, ProdMaster, вы можете каким-то образом индексировать 3 последовательности ветвей. Например, если вы работаете над версией 55 вашего продукта, у вас могут быть DevMaster55-1, DevMaster55-2, DevMaster55-3 (для каждого раунда утверждения, если есть несколько раундов), TestMaster55 для тестирования версии 55 и ProdMaster55 (актуальный выпуск v55, который должен поступить в производство).

Преимущество этого заключается в том, что вам не нужно синхронизировать эти последовательности (например, TestMaster56 будет отделен от TestMaster55), а история изменений в каждой из этих ветвей очень чистая. На практике ProdMaster55 может быть просто тегом в ветви TestMaster55, а TestMaster55 - это «стабилизационная» ветка, которая в какой-то момент вылетела из мастера и принимает только исправления, необходимые для v55.

...