Примечание: мой вопрос сосредоточен на моей конкретной проблеме (которая включает в себя Liferay), но я надеюсь, что это может быть полезно для всех, кому нужно поддерживать различные версии одного и того же проекта в git.
Я работаю в компании, которая пишет много плагинов для Liferay Portal . Эти плагины (портлеты, темы и т. Д.), Как правило, могут быть использованы повторно и, конечно, должны быть обновлены для новых версий портала.
Однако обычно приходится переносить, скажем, портлет в новую версию Liferay и поддерживать его предыдущую версию. Кроме того, часто нам приходится создавать очень специфические настройки для некоторых клиентов, которые не имеют смысла добавлять в «основную версию».
Эти реквизиты усложняют нашу работу, но, к счастью, мы можем предположить некоторые упрощения. Например, плагины часто обновляются только одним программистом за раз. Очень редко две или более функций добавляются в плагин одновременно.
Теперь мы мигрируем в Gitorious . Мы пытаемся создать модель ветвления для такого сценария.
Моя модель
Я предложил следующее:
- Каждый плагин будет иметь свой собственный репозиторий в Gitorious внутри проекта. Например, портлет для отображения котят будет иметь
kittens-portlet
репозиторий внутриliferay-portlets
проекта. - При создании нового плагина создайте его в ветке с именем в соответствии с версией Liferay (например,
lf5.2
). - Каждый раз, когда производится обновление плагина, оно утверждается и развертывается в рабочей среде, пометьте плагин версией (например,
lf5.2v1
иlf5.2v2
т. Д.) * - Каждый раз, когда плагин должен быть портирован на новую версию Liferay, мы разветвляем самую последнюю версию (создавая, например, ветку
lf6.0
). - После запуска руководитель нового филиала получит такой тег, как
lf6.0v1
. - Каждый раз, когда нам нужно настроить плагин для конкретного клиента, мы создаем ветку с именем клиента (например, мы создаем ветку
lf5.2clientcorp
для нашего клиента "ClientCorp Inc.")
Это необычная модель: в ней не было бы master
и много не сливающихся веток. Вот как я думаю, что репозиторий с такой моделью будет выглядеть так:
Друг нашел эту систему довольно сложной и подверженной ошибкам. Он предложил отличную и популярную модель Винсента Дриссена , которую я нашел еще труднее управлять и дисциплинировал. Это здорово (и проверено!) Конечно, но кажется слишком сложным в нашей ситуации.
Модель моего друга
Затем он предложил другую модель: у нас будет хранилище для каждого плагина в версии Liferay (поэтому мы начнем создавать a, kittens-lf5.2-portlet
а затем a kittens-lf6.0-portlet
), каждый с master
ветвью и develop
ветвью. master
Будет всегда готов к развертыванию. (Или это может быть наоборот, master
и stable
, как предполагает Стив Лош ).
Это очень просто, но мне не понравилась эта система:
- это может привести к огромному количеству репозиториев в проекте, что затруднит просмотр Gitorious.
- Название каталога проекта актуально. Если кто-то клонирует репозиторий в
kittens-lf6.0-portlet
dir и сгенерирует WAR с помощью ant (как обычно), то будетkittens-lf6.0-portlet
также указано имя WAR . Старые версии этого портлета (названные,kittens-portlet
например) будут рассматриваться как разные (и, вероятно, отсутствующие) портлеты в обновленном портале. Осторожности можно избежать, но я бы предпочел этого избежать. - Различные версии одного и того же плагина будут поддерживаться отдельно. Я разбиваю свое сердце :(
kittens-lf6.0-portlet
я думаю, это уродливое имя для хранилища.
Я подозреваю, что два последних пункта, а также два более субъективных, являются основной причиной моего нежелания. Тем не менее все четыре возражения остаются в силе.
ОТО, мое собственное предложение кажется мне странным, и мне интересно, есть ли в нем скрытые ошибки. OT3rdH git настолько мощен и гибок, что, думаю, мне не стыдно исследовать его возможности.
Итак, я спрашиваю:
- Какой будет лучшая модель? Мое предложение? Модель моего друга? Теперь традиционная система Винсента Дриссена?
- Какую другую модель ветвления вы бы предложили?
- Если вы думаете, что моя модель плохая, почему вы так думаете? Я хотел бы узнать, каковы недостатки и слепые пятна.
* На самом деле, я бы предпочел пометить коммит такой версией, как, v1
но, очевидно, тэг в git не ограничен в ветке - то есть я не мог иметь 1 v1
тэг lf5.2
и еще один lf6.0
- поэтому я должен назвать ветвь. Это правильно, кстати?
источник
Ответы:
Если я правильно прочитал, ответвления в основном представляют собой однократное отклонение от вашей основной линии разработки, никогда не предназначенные для слияния обратно с основной линией, и достижения в основной строке никогда не применяются к этим ветвям. Единственное отклонение состоит в том, что исправления ошибок, соответствующие версии, на которой была основана ветвь, должны быть применены к ветке.
Ответ теперь имеет решающее значение для вашего повседневного рабочего процесса, количество разработчиков, работающих над какой-либо одной ветвью, или количество изменений - красные сельди. Я вижу вашу основную потребность в том, чтобы узнать, какие ветви получают обновление для исправления ошибок после изменения основной ветви, и для этого я думаю, что объединенный репозиторий с ветвями будет более эффективным, поскольку все это в одном месте. Если бы никогда не было необходимости перекрестного опыления, то отдельные хранилища могли бы обеспечить это, но этот сценарий не соответствует реальности вашего проекта, насколько я понимаю.
Модель Дриссена работала бы хорошо, если бы вашему проекту требовалось объединить ветви обратно в основную линию разработки, но вам это не нужно. Тем не менее, я думаю, что есть смысл поддерживать концепцию InDevelopment и StableRelease, если вы работаете над живым продуктом.
Подводя итог, я думаю, что ваш проект будет хорошо работать с вашей моделью ветвления плюс черта Дриссена для вашей основной линии. Ваш пробег может варьироваться; Я всегда работал с веткой «ожидающего выпуска», которая превращается в «живую» ветку, и отдельной «следующей версией», которая требует перекрестного опыления исправлений и изменений в различных точках, поэтому моё восприятие может быть предвзятым.
источник
Меня сбивает с толку тот факт, что у каждого портлета есть свой собственный репозиторий (но ваша история может быть не полной). Лично я бы создал хранилище для каждого проекта. Проекты часто имеют несколько портлетов, и все они собираются в одну и ту же версию для одной и той же версии Liferay. Каждый проект может быть дубликатом существующего проекта, созданного с использованием другой версии Liferay, но я бы разделил продукт, только если различия слишком велики. Если сборка работает против Liferay 5.1 и 5.2, я бы не разбивал проект. Я хотел бы использовать сценарии или Maven (или оба), чтобы все работало. Я бы использовал Wiki (или Trello) для управления каждым продуктом и с какой версией Liferay он может быть построен.
Кстати, я программист на Java, специалист по Maven, специалист по сборке и имею опыт работы с Liferay и другими серверами портала (IBM WebSphere и Glassfish).
Но это всего лишь мои 0,02 евро.
источник