Git-flow, gerrit и перебазирование на более новую версию основной ветки разработки

Рассмотрим локальное репо, управляемое gerrit, которое регулярно синхронизируется с проектом на основе github (с соответствующими ветками/тегами отслеживания. Разработка была инициализирована в версии 1 кода (тег = 1.0). Разработка ведется на этом коде и регулярно объединяется с внутренней веткой разработки через gerrit и, возможно, также с внутренней веткой выпуска/мастера.

В конце концов, однако, желательно, чтобы мы перешли на внешнюю версию 2.0 или чтобы мы извлекли все изменения из нашей линии выпуска (после того, как она отклонится от разработки).

Учитывая, что это код, управляемый через gerrit, будете ли вы напрямую перебазировать ветку разработки, чтобы внести внутренние/внешние «восходящие» изменения в вашу строку разработки, или вы перебазируете из разработки, перебазируете ветвь разработчика в v2.0, а затем протолкнуть ветвь разработчика через gerrit обычным способом?

Я спрашиваю, потому что первый кажется нестандартным в этой структуре... из того, что я читал по этому вопросу (например, здесь) такая перебазировка на месте может быть невозможна в gerrit и может быть нежелательной, если мы регулярно отправляем все другим командам (что в конечном итоге может произойти). Последний вариант (pull-via-developer-branch) кажется более надежным и не требует от разработчика особых привилегий для обхода gerrit или обычного процесса разработки.

Твои мысли?


person MartyMacGyver    schedule 30.10.2012    source источник