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

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

Есть две предпосылки для моей проблемы:

  • Gerrit будет выполнять только слияние с одной ветвью
  • Я не допускаю, чтобы комманды слияния были перенесены на Gerrit. Слияние должно быть выполнено Gerrit после одобрения изменений.

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

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

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

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

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

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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

Лучшее решение, безусловно, должно объединить либо мастер, либо ветвь исправления в вашу ветку разработки. Я не уверен, что ваше предварительное условие "не слияния" пытается решить, но это, вероятно, создаст больше хлопот, чем того стоит.

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