Каков наилучший способ управления исправлением ошибок в версиях данного решения?

Question

Я пытаюсь использовать Git для управления различными версиями продукта. Есть несколько способов сделать это. Я знаком с концепцией наличия «ведущей» ветви и обозначением разных точек вдоль этой ведущей ветви, чтобы она называлась «Версии» решения. Например, в какой-то момент времени я могу решить, что текущая сборка представляет собой сборку «RP_2012» моего продукта. Позже, после добавления некоторых дополнительных функций, может быть версия «RP_2013» и т. Д.

Мне кажется, что хотя разработка может быть завершена на определенной «версии», исправления ошибок могут по-прежнему выкатиться. Например, я работаю в Azure, и у каждого клиента есть своя версия решения, а не многопользовательская договоренность (потому что таким образом я получаю возможность предлагать им новые версии продукта, если они хотят заплатить обновления, и они могут оставаться с более старыми версиями продукта, которым они удобны, пока они не будут готовы к обновлению, а не будут добавлены новые функции). У меня есть сценарий, который использует комбинацию TeamCity, FluentMigrator и т. Д., Чтобы иметь возможность использовать версию определенного клиента и обновлять ее по своему усмотрению, сохраняя при этом свои существующие данные. Таким образом, в то время как любые новые функции, которые добавляются к продукту, будут создаваться на их собственной ветке, затем объединены в Head of master для выпуска в какой-либо будущей версии, также должна быть возможность делать исправления ошибок, которые могут быть применены к любые/все версии продукта, которые в настоящее время используются/поддерживаются.

Если я использую подход с маркированной версией и одну ветвь «ведущий», как обсуждалось выше, развертывание таких исправлений ошибок может оказаться невозможным. Если я вместо этого предоставил каждой версии свою собственную ветку, можно было бы выполнить исправления ошибок в отдельной ветке, которая происходит от предка каждой из ветвей «версии», а затем объединить эту ветвь в несколько отдельных, специфичных для конкретной версии ветви? Или может быть какой-то умный способ использовать Rebase, чтобы, если у меня есть исправление ошибок, которое повлияет на версии 10, 11, скажем, и эти «версии» являются просто помеченными точками вдоль главной ветви, могу ли я просто отделиться от точка, помеченная как «версия 10» в главном, и как-то переустановить мастер, чтобы основываться на исправлениях, которые будут выполняться в упомянутой ветке исправления ошибок, тем самым гарантируя, что версии 10 и выше все получат выгоду от исправлений данных адресов филиала? В то же время, конечно, любые новые функции можно было бы сделать, отделившись и сместившись обратно в голову мастера.

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

Заранее благодарим за любые предложения.

Answer 1

Я бы предложил использовать «git flow» для этого. Это расширение для git для обработки используемого варианта, который вы описываете, с одним мастером и развитием ветки, отдельными ветвями выпуска и отдельными ветвями функций. См. this и this запись в блоге для подробного описания используемой модели ветвления.

Вы должны быть очень осторожны в использовании переустановки для целей, которые вы описываете. Rebase будет переписать историю версий, которая сделает ее очень запутанной и сложной, если есть коммиты от людей с «разными» версиями версий.

Answer 2

Я не думаю, что существует объективный способ определить, что такое best здесь.

Лично я всегда придерживаюсь модели с 1 веткой за выпуск. Тем более, если у вас несколько клиентов. Иногда даже клиент запрашивал пользовательскую функцию, поэтому вы отключаете свою ветку для младшего выпуска и так далее.

В вашем случае, если вы идете с моделью с несколькими ветвями, и у вас есть исправление ошибки, которое вы хотите применить к некоторым ветвям, вы могли бы cherry-pick исправить/зафиксировать все ветви, которые в ней нуждаются.

Кроме того, отметьте this question, запрашивающий предоставляет сценарий для одновременного ввода нескольких ветвей. Используя вишневый выбор, если на то пошло.