Как управлять номерами версий POM в git без конфликтов слияния

У меня возникли проблемы с пониманием того, как использовать номера версий. В моей команде наш основной рабочий процесс работает следующим образом. Цикл разработки в моей команде выглядит так.

Непрерывная разработка осуществляется в нашей среде разработки. Раз в месяц у нас происходит заморозка кода, когда текущая версия приложения развертывается в отдельной среде контроля качества, где наши специалисты по контролю качества проверяют его на стабильность и наличие ошибок, которые пропустили разработчики. Как только QA будет удовлетворен (это займет от 1 до 2 недель в зависимости от рабочей нагрузки QA), версия QA будет развернута на наших рабочих серверах.

Мы переходим с Subversion на Git, и я пытаюсь разработать нашу стратегию ветвления/выпуска для поддержки этого. Что я хотел бы сделать, так это:

Начальная точка: DEV работает на версии 1.0-SNAPSHOT на master
При заморозке кода: Создайте новую ветвь release-1.0 из master. Увеличьте POM на master до 1.1-SNAPSHOT
После контроля качества: разверните версию 1.0 на нашем сервере связи и пометьте репозиторий. Объедините release-1.0 в master, чтобы любые исправления ошибок или изменения были интегрированы в будущие выпуски.

Проблема в том, что когда я объединяю release-1.0 в master, я получаю конфликт слияния с версией POM. <version>1.1-SNAPSHOT</version> конфликтует с <version>1.0</version>. Конфликт слияния легко разрешить, но он не позволяет мне автоматизировать этот шаг.

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

Я хотел бы избежать вишневого выбора коммитов из ветки релиза в мастер, просто чтобы исключить возможность чего-то упустить и не слиться с мастером.

Есть ли способ управлять этим с помощью плагина maven-release, или я обречен делать это вручную?


git versioning maven-release-plugin
person GridDragon    schedule 15.12.2016    source источник
comment
Но не будут ли всегда возникать конфликты слияния в других файлах, которые в любом случае требуют ручного разрешения при каждом слиянии?   -  person Tim Biegeleisen    schedule 15.12.2016
comment
Согласен с @TimBiegeleisen, если вы отправляете исправления в основную ветку для каких-либо ошибок, у вас все равно будет конфликт слияния в этом файле. А если это отдельный релиз, то можно сделать и с накаченной версией.   -  person Naman    schedule 15.12.2016
comment
Существует такая вещь, как выполнение слияния и указание либо --theirs, либо --ours, чтобы безоговорочно принять версию вещей одного родителя. Но поскольку у вас, вероятно, есть другие файлы, кроме вашего POM, вы выбросите ребенка вместе с водой из ванны, слепо принимая одну версию каждого файла вместо другой.   -  person Tim Biegeleisen    schedule 15.12.2016
comment
Раньше я пытался использовать пользовательский фильтр слияния: stackoverflow.com/q/22909620/6309   -  person VonC    schedule 15.12.2016

Ответы (1)


arrow_upward
3
arrow_downward

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

Сегодня это обычное дело в программных проектах. Это путь Maven, но также и путь Linux, однако я не думаю, что Линус примет конфликтующий патч в номере выпуска ядра или кодовом имени - они следуют модели, отличной от большинства проектов.

Альтернативой является сохранение специальной версии «0-SNAPSHOT» (в терминах Maven) в исходном коде и изменение ее только после ее выпуска. Тогда все ветки разработки согласятся, и я считаю, что это то, что вы хотите.

Обратите внимание, что Maven не разработан с учетом этого, и вы столкнетесь с проблемами. Например, как вы объясните своему тестировщику, что окончательный выпуск (1.0) имеет хэш SHA1, отличный от утвержденного (1.0-rc-5), только потому, что вы изменили числа в исходном коде?

Если вы полностью уберете номер версии из исходников проекта, это перестанет быть проблемой. Боюсь, я не нашел, что это Maven Way. Нам нужны лучшие инструменты.

person sevo    schedule 07.09.2017