Gerrit: работа с несколькими ветками и распространение изменений

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

Сейчас мы работаем с ветками так: у нас есть ветка master и feature. Мастер — это ветка, которую мы хотим отшлифовать и подготовить к выпуску, а фича — это, очевидно, область интенсивной работы. Теперь, в нашем конкретном случае, всякий раз, когда кто-то работает над исправлением ошибки, он:

  • создать изменение, предназначенное для главной ветки
  • вишневый выбор в целевое изменение функциональной ветки
  • после завершения проверки кода gerrit отправьте оба изменения.

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

Теперь я решил все эти проблемы, применив стратегию слияния (наша на фиче, их на мастере), но это кажется неправильным: если что-то не распространялось, оно просто отбрасывалось.

У меня такой вопрос: существует ли безопасный рабочий процесс, похожий на описанный выше, который в конце концов приведет к чистому слиянию с gerrit?


merge branch branching-and-merging gerrit
person Tomasz W    schedule 28.07.2012    source источник

Ответы (2)


arrow_upward
9
arrow_downward

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

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

Я бы предложил другой способ работы.

  • Когда вы выполняете обычную работу, вы разрабатываете функцию и отправляете Герриту как обычно.
  • Когда вы делаете патч (то есть исправление ошибки) в стабильной производственной среде, вы делаете это непосредственно на мастере (или локальных ветках, если хотите, но не на функции)
  • Когда исправление утверждается в Gerrit, оно объединяется с настоящим мастером, и вы можете сделать запрос pull, чтобы внести это изменение в свою локальную копию. Ваша версия master теперь совпадает с master Gerrits.
  • Теперь вы объедините все новые изменения в master с feature. Убедитесь, что вы выполнили перебазирование, чтобы исправление завершилось раньше всего, что вы уже сделали с функцией.
  • Когда придет время развертывать все новые функции, вы можете объединить feature в master, отправить в Gerrit (если у вас есть разрешения, вы можете обойти gerrit, отправив прямо в master вместо refs/for/master, так как эти изменения уже проверены)
  • После внесения всех изменений в master Gerrits вы выполняете извлечение своего master и слияние с feature с помощью rebase. представить чистую ветку для работы. Конечно, в каждом выпуске должна быть новая функция. Оба работают нормально.
person Andreas Wederbrand    schedule 04.02.2013

arrow_upward
0
arrow_downward

Я немного смущен, так как этот поток должен работать нормально. Если другие пользователи отправят изменения до того, как ваше исправление будет просмотрено/проверено/отправлено, это может привести к конфликтам слияния, но это должно быть редко.

Если ты:

  1. Исправить ошибку на мастере
  2. Нажмите для просмотра (создание изменения A в gerrit)
  3. вишневое изменение A поверх ветки функций (разрешение любых конфликтов от мастера к функции)
  4. Отправьте выбранное изменение на рассмотрение (создание изменения B)
  5. Просмотр/проверка/отправка изменений A и B

Все будет работать нормально. Единственный способ возникновения конфликтов слияния — это загрузка и отправка изменений другими пользователями между шагами 1 и 5. Наблюдаете ли вы другое поведение? Можете ли вы предоставить более подробную информацию?

person Brad    schedule 31.07.2012
comment
нет, это не так. однако есть разница между тем, что вы сказали, и тем, что мы делаем. разница в том, что мы обычно выбираем изменения еще до того, как они будут отправлены на проверку (то есть локально). может в этом проблема..? дело в том, что некоторые люди даже получают одобрение, прежде чем создать вишневый выбор (крупные коммиты), и это все еще проявляется как конфликт. я полагаю, может оказаться, что нам нужно выбирать представленные изменения, а не локальные ветки.. - person Tomasz W; 02.08.2012
comment
Не имеет значения, выбираете ли вы вишенки до или после того, как нажали на просмотр. Я не уверен, что вы подразумеваете под получением одобрения перед созданием вишни. - person Brad; 03.08.2012
comment
когда вы отправляете изменения в gerrit, эти изменения не сразу объединяются. вместо этого они являются кандидатами для данной ветки, объединяются с этими ветвями, когда вы «отправляете» свой набор исправлений. это означает, что слияние не выполняется в вашем локальном репозитории, и кажется, что оно также получает отдельную сумму SHA (я не слишком глубоко разбираюсь в деталях gerrit, поэтому я не знаю, почему это происходит). я думаю тот факт, что между нашими вишневыми пиками и этими удаленными ша-суммами нет корреляции, rebase/merge просто не понимает, что происходит (он видит эквивалентные изменения на обеих ветках и трактует их как конфликты) - person Tomasz W; 09.08.2012