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