Рабочий процесс проверки Gerrit: конфликты слияния и повторное утверждение

Мы рассматриваем возможность использования Gerrit для большого проекта. На данный момент было бы интересно узнать, как люди справляются с конфликтами слияния утвержденных изменений.

Представьте, что на доработке одновременно находится множество изменений разного размера, и они пересматриваются и проверяются постепенно. Поскольку некоторые из них могут модифицировать один и тот же фрагмент кода, конфликты неизбежны. Это не проблема, если «интегратор» принимает исправления вручную в простом рабочем процессе, небольшие конфликты могут быть разрешены в пути, но с Gerrit все по-другому. Когда изменение будет проверено и одобрено, в случае конфликта слияния, как я понимаю, автору необходимо будет перебазировать его и снова отправить на доработку, и в этом случае процесс доработки начнется снова. В относительно активных проектах с более чем 50 фиксациями внешних участников в неделю это может превратиться в кошмар, если может потребоваться повторная проверка одного и того же патча несколько раз из-за отклонения слияния после каждого утверждения и отправки, что кажется не эффективно.

Вопросы:

  1. Правильно ли я понимаю, что Gerrit не подходит для больших и активных вещей, где ожидается большое количество конфликтов слияния?

  2. Некоторые конфликты слияния могут быть тривиальными, есть ли способ разрешить их, не беспокоя автора повторной фиксацией изменения?

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

Общие комментарии о вашем опыте рабочего процесса Gerrit также приветствуются.


person Ruslan Kabalin    schedule 04.04.2012    source источник


Ответы (4)


  1. Gerrit используется некоторыми действительно крупными проектами, такими как Android и связанные с ним репозитории bsp, kernel и т.д. Эти проекты получают более 50 внешних коммитов в неделю. Я думаю, что Qualcomm сделает несколько тысяч коммитов примерно за это время.

  2. В Gerrit есть настройка для автоматического слияния тривиальных конфликтов. Это может быть установлено для каждого репозитория. Если этот параметр установлен, изменение вносится в соответствии с вашей стратегией отправки (выборка, объединение при необходимости) после того, как изменение было просмотрено и проверено, и пользователь нажимает кнопку «Отправить». Лучшая документация, которую я смог найти для этого, находится здесь http://gerrit-documentation.googlecode.com/svn/Documentation/2.3/cmd-create-project.html#_options в параметре --use-content-merge.

  3. Да, обычно так мы и поступаем. Есть и другие варианты (обход проверки, объединение веток и т. д.), но выбор нужных веток и проверка работают хорошо.

person Brad    schedule 05.04.2012

Мы хотим, чтобы наша история была чистой и понятной, а значит, достаточно линейной. Итак, мы настроили Gerrit на использование только быстрого слияния. Единственные видимые слияния — это ветки релиза и поддержки (мы используем git-flow), что значительно упрощает понимание.

Однако у нас установлен плагин тривиальной перебазировки, так что предыдущий статус проверки автоматически применяется к перебазированному изменению. Это происходит независимо от того, выполняется ли перебазирование в Gerrit (с помощью кнопки Rebase) или разработчик выполняет локальное перебазирование и повторно отправляет изменение.

По нашему опыту, конфликты слияния на самом деле менее распространены в больших проектах из-за гораздо большего количества задействованных исходных файлов. У нас около 16 000 файлов в репозитории и 30 разработчиков, работающих полный или неполный рабочий день, поэтому вероятность редактирования одного и того же файла довольно мала.

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

person Neil Mayhew    schedule 08.11.2012
comment
Нил, мне бы хотелось узнать больше о вашем рабочем процессе gerrit + git-flow. Вы это где-нибудь задокументировали? Спасибо. - person spazm; 09.11.2012
comment
@spazm github.com/sillsdev/FwDocumentation/wiki — это все, что у нас есть прямо сейчас, и это для наших внутренних разработчиков. Однако, если есть что-то еще, что вы хотели бы узнать, не стесняйтесь обращаться ко мне напрямую. Мы все еще совершенствуем наши процессы, поэтому взаимодействие с другими людьми, которые следуют тому же пути, полезно. - person Neil Mayhew; 16.11.2012

Когда мы сталкиваемся с проблемой слияния в нашей компании, разработчик перебазирует и отправляет на gerrit. Если слияние было минимальным, ему разрешено (по соглашению) LGTM перебазировать и отправить.

Мы все еще обсуждаем, должны ли разработчики выполнять перебазирование при обновлении наборов исправлений. Пользовательский интерфейс сбивается при сравнении наборов исправлений при изменении родителя.

person spazm    schedule 26.04.2012
comment
Мы стараемся, чтобы перебазирование не включало никаких других изменений, чтобы было легче отделить реальные обновления от шума перебазирования. - person Neil Mayhew; 08.11.2012

Я использую его в течение нескольких недель после использования mercurial в течение нескольких лет с веткой функций, объединенной в режим по умолчанию, и я ненавижу gerrit. Я обнаруживаю, что у меня больше накладных расходов на решение тривиальных конфликтов, которые автоматически решаются путем слияния на mercurial или git в режиме без gerrit. Затем все используют аргумент, что андроид использует gerrit, следовательно, gerrit — это хорошо и должно работать для всех.

person piotr    schedule 13.06.2014