Рабочий процесс Git и Gerrit

Question

Я пытаюсь реализовать рабочий процесс типа «git-flow» с использованием Gerrit, но, похоже, не могу понять последнюю часть головоломки.

У моей проблемы есть два предварительных условия:

• Геррит будет выполнять слияние только с одной веткой
• Я не разрешаю передавать коммиты слияния на Геррит.Объединение должно быть выполнено Герритом после утверждения изменений

Я хочу решить следующее.Рассмотрим ситуацию с git:

Master 0 
        \
         \
Develop   0-----0-----0-----0

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

Теперь предположим, что кто-то создает ветку исправлений из мастера и сливается обратно с мастером:

Master 0--------0 HF 
        \
         \
Develop   0-----0-----0-----0

Этот коммит теперь только объединяетсяосновная ветвь, но разработчики нуждаются в этом коммите в своей ветке разработки, чтобы включить исправление в свои изменения.Обычно вы объединяете главную ветвь для разработки ветки разработки, но, учитывая мои предварительные условия, это невозможно, так как это создаст локальный коммит слияния.

Мой вопрос: как мне включить новые коммиты из основной веткив локальную ветку разработки, чтобы любые новые изменения от разработчиков содержали исправление?В идеале я бы изменил свой сценарий, чтобы сначала применить изменения исправлений к локальной ветви разработки (слияние, но без фиксации слияния), а затем перебазировать коммиты dev и нажать.Таким образом, исправление будет автоматически добавлено к их новым изменениям и будет рассматриваться как таковое, как часть их новых коммитов, а не отдельного коммита.

Я думал о возможных решениях:

• Черри выбирает коммит в ветке разработки.Я полагаю, что это всегда приведет к дублированию коммита, когда в следующий раз развернутся с master.Есть ли способ обойти это?
• Перебазирование, как описано здесь: http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/.Это, вероятно, вызывает проблемы, так как ветка разработки опубликована, или нет?

Надеюсь, мой вопрос ясен.Пожалуйста, дайте мне знать, если это требует дальнейших разъяснений.Я знаю, что я довольно жестко отношусь к своему рабочему процессу, но это было бы идеально в сочетании с Герритом.Если это невозможно, я, вероятно, разрешу коммиты слияния ...

Answer 1

После рассмотрения вариантов я решил отказаться от этого метода.Мне кажется, что Gerrit в большей степени нацелен на разработку единой ветки интеграции.

Когда изменения необходимо объединить в две ветви (например, исправление, которое нужно освоить и разработать), оно заставляет вас перепрыгивать через все виды обручей, которые составляют дополнительную работу / просмотр.Я решил придерживаться одной ветви.

Я думаю, что модель потока Git не очень подходит для дизайна Gerrit.Если бы другие люди интегрировали Gerrit с Git flow, я бы хотел услышать об их методах.

Answer 2

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

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Answer 3

Лучшее решение, безусловно, - объединить ветку master или hotfix с вашей веткой разработки.Я не уверен, что пытается решить ваша предусловие «без слияния», но, вероятно, это создаст больше хлопот, чем стоит.

С другой стороны, если вы выбираете «черри», git обычнообнаружить дублирующий коммит во время слияния и автоматически объединить его без проблем.Но когда есть проблемы, им не будет весело.Также не так ясно, какие исправления были выбраны вишней, а какие нет, где, как при слиянии, это очень ясно.