Примечание: мой вопрос сосредоточен на моей конкретной проблеме (которая включает в себя Liferay), но я надеюсь, что это может быть полезно для всех, кому нужно поддерживать различные версии одного и того же проекта в git.

Я работаю в компании, которая пишет много плагинов для Liferay Portal . Эти плагины (портлеты, темы и т. Д.), Как правило, могут быть использованы повторно и, конечно, должны быть обновлены для новых версий портала.

Однако обычно приходится переносить, скажем, портлет в новую версию Liferay и поддерживать его предыдущую версию. Кроме того, часто нам приходится создавать очень специфические настройки для некоторых клиентов, которые не имеют смысла добавлять в «основную версию».

Эти реквизиты усложняют нашу работу, но, к счастью, мы можем предположить некоторые упрощения. Например, плагины часто обновляются только одним программистом за раз. Очень редко две или более функций добавляются в плагин одновременно.

Теперь мы мигрируем в Gitorious . Мы пытаемся создать модель ветвления для такого сценария.

Моя модель

Я предложил следующее:

1. Каждый плагин будет иметь свой собственный репозиторий в Gitorious внутри проекта. Например, портлет для отображения котят будет иметь kittens-portletрепозиторий внутри liferay-portletsпроекта.
2. При создании нового плагина создайте его в ветке с именем в соответствии с версией Liferay (например, lf5.2).
3. Каждый раз, когда производится обновление плагина, оно утверждается и развертывается в рабочей среде, пометьте плагин версией (например, lf5.2v1и lf5.2v2т. Д.) *
4. Каждый раз, когда плагин должен быть портирован на новую версию Liferay, мы разветвляем самую последнюю версию (создавая, например, ветку lf6.0).
5. После запуска руководитель нового филиала получит такой тег, как lf6.0v1.
6. Каждый раз, когда нам нужно настроить плагин для конкретного клиента, мы создаем ветку с именем клиента (например, мы создаем ветку lf5.2clientcorpдля нашего клиента "ClientCorp Inc.")

Это необычная модель: в ней не было бы masterи много не сливающихся веток. Вот как я думаю, что репозиторий с такой моделью будет выглядеть так:

Друг нашел эту систему довольно сложной и подверженной ошибкам. Он предложил отличную и популярную модель Винсента Дриссена , которую я нашел еще труднее управлять и дисциплинировал. Это здорово (и проверено!) Конечно, но кажется слишком сложным в нашей ситуации.

Модель моего друга

Затем он предложил другую модель: у нас будет хранилище для каждого плагина в версии Liferay (поэтому мы начнем создавать a, kittens-lf5.2-portletа затем a kittens-lf6.0-portlet), каждый с masterветвью и developветвью. masterБудет всегда готов к развертыванию. (Или это может быть наоборот, masterи stable, как предполагает Стив Лош ).

Это очень просто, но мне не понравилась эта система:

1. это может привести к огромному количеству репозиториев в проекте, что затруднит просмотр Gitorious.
2. Название каталога проекта актуально. Если кто-то клонирует репозиторий в kittens-lf6.0-portletdir и сгенерирует WAR с помощью ant (как обычно), то будет kittens-lf6.0-portletтакже указано имя WAR . Старые версии этого портлета (названные, kittens-portletнапример) будут рассматриваться как разные (и, вероятно, отсутствующие) портлеты в обновленном портале. Осторожности можно избежать, но я бы предпочел этого избежать.
3. Различные версии одного и того же плагина будут поддерживаться отдельно. Я разбиваю свое сердце :(
4. kittens-lf6.0-portlet я думаю, это уродливое имя для хранилища.

Я подозреваю, что два последних пункта, а также два более субъективных, являются основной причиной моего нежелания. Тем не менее все четыре возражения остаются в силе.

ОТО, мое собственное предложение кажется мне странным, и мне интересно, есть ли в нем скрытые ошибки. OT3rdH git настолько мощен и гибок, что, думаю, мне не стыдно исследовать его возможности.

Итак, я спрашиваю:

1. Какой будет лучшая модель? Мое предложение? Модель моего друга? Теперь традиционная система Винсента Дриссена?
2. Какую другую модель ветвления вы бы предложили?
3. Если вы думаете, что моя модель плохая, почему вы так думаете? Я хотел бы узнать, каковы недостатки и слепые пятна.

* На самом деле, я бы предпочел пометить коммит такой версией, как, 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 евро.