Поддерживаем разработку нескольких версий продукта в Git. Станислав Лукьянов (GridGain)

Boomburum deniskin Здравствуйте.
Тут верстка Хабра неправильно отображается.

На правах первонаха напишу длинный коммент.

Идея в докладе предлагается интересная: разветвиться по поддерживаемым версиям, на каждую завести свой мастер.
Кажется, предлагается методология по работе с гитом (+ инструменты кросс-валидации git и jira), которая частично покроет проблемы, связанные с неумением гита в спонтанное ветвление.

Я не понимаю, почему master-first подход возможен на практике. При черри-пике любое изменение может (а по моему опыту — почти всегда) перенестись из ветку в ветку, полностью изменив смысл своих изменений в контексте другой версии кода. В лучшем случае код станет просто синтаксически некорректным, в худшем — появится трудноуловимая бага, специфичная именно для этой версии и, быть может, более ранних. Тогда, кмк, после каждого черри-пика надо проводить стабилизацию каждой ветки.

Например, при переходе между версиями 1.3 и 1.4 вместо одной зависимой библиотеки была использована другая (или другая версия этой же библиотеки) с похожим функционалом и похожим API. Фикс баги в мастере состоял в том, что некоторая библиотечная функция стала вызываться с другими аргументами/параметрами. При черри-пике мы можем получить

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

Другой пример: при переходе между мажорными или минорными версиями меняется механизм или алгоритм работы с памятью/файлами/сетью/железом/данными/конфигами (или сам язык конфигов или DSL меняется). Черри-пик багфикса не обязан быть багфиксом в более ранней версии.

Вот, что говорит докладчик:

Я согласен. Но здесь мы решаем проблему 99 % случаев. И 1 %, когда мы дропнули performance каким-то bugfix’ом в 2 раза и нашли это во время тестирования, а bugfix уже везде промержен, то мы в ручном режиме примем какое-то решение. Может быть, мы сделаем откат, но, скорее всего, мы очень быстро будем фиксить это по всем веткам.

Фактически, он говорит, что багфиксы к черри-пикнутым багфиксам будут писаться вручную, но рассматривается это как внештатная ситуация. Не понимаю, как им удаётся избегать багов, созданных неправильным переносом багфиксов.