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

Я працюю над компанією, яка пише багато плагінів для порталу Liferay . Ці плагіни (портлети, теми тощо) зазвичай використовуються повторно і, звичайно, повинні бути оновлені для нових версій порталу.

Однак зазвичай потрібно перенести, скажімо так, портлет на нову версію 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 за допомогою мурашки (як зазвичай), WAR буде kittens-lf6.0-portletтакож ім'ям . Старі версії цього портлета (названі kittens-portletнаприклад) вважатимуться різними (і, мабуть, відсутніми) портлетами на оновленому порталі. Трохи турботи можна цього уникнути, але я вважаю за краще уникати цього.
3. Різні версії одного і того ж плагіна будуть підтримуватися окремо. Я розбиваю серце :(
4. kittens-lf6.0-portlet гадаю, це ім'я сховища.

Я підозрюю, що два останні моменти - які є ще двома суб'єктивними - є головною причиною мого небажання. Тим не менш, усі чотири заперечення стоять.

ОТО, моя власна пропозиція здається мені дивною, і мені цікаво, чи є на ній приховані помилки. Git OT3rdH настільки потужний і гнучкий, що, на мою думку, мені не слід соромитися, вивчаючи його можливості.

Отже, я прошу:

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

* Насправді я вважаю за краще тег фіксувати за допомогою такої версії, як, v1але, мабуть, тег у git не входить у гілку - тобто я не міг би мати 1 v1тега lf5.2та ще один lf6.0- - тому я маю назвати ім'я відділення. Чи правильно BTW?

Якщо я прочитав це правильно, гілки - це в основному однократне відхилення від вашої основної лінії розвитку, яке ніколи не означало об'єднання назад в основну лінію, а досягнення в основній лінії ніколи не застосовуються до цих гілок. Єдине відхилення полягало б у тому, що виправлення помилок, відповідні версії, за якою базується галузь, потрібно застосувати до гілки.

Відповідь зараз визначається у вашому робочому процесі щоденно, кількість розробників, які працюють на будь-якій одній гілці, або кількість змін - це червоні оселедці. Я вважаю, що ваша основна потреба хоче знати, які гілки отримують оновлення виправлення помилок від основної зміни гілки, і для цього я думаю, що комбінований сховище з гілками буде більш ефективним, оскільки це все в одному місці. Якщо ніколи не було необхідності в перехресному запиленні, то окремі сховища могли б це застосувати, але цей сценарій не відповідає дійсності вашого проекту, як я його розумію.

Модель Дріссена спрацювала б добре, якби ваш проект потребував об’єднання гілок назад в основну лінію розвитку, але це вам не потрібно. Навіть тому я вважаю, що в підтримці концепції InDevelopment та StableRelease є заслуга, якщо ви працюєте над продуктом, який живе.

Отже, підводячи підсумок, я думаю, що ваш проект добре співпрацював би з вашою моделлю розгалуження плюс тире Дріссена для вашої основної лінії. Ваш пробіг може змінюватися; Я завжди працював з гілкою "очікуваний випуск", яка перетворюється на "живу" гілку, і окремим "наступним випуском", які вимагають перехресного запилення виправлень та змін у різних точках, так що моє сприйняття може бути упередженим.

Що мене спотикає, той факт, що кожен портлет має власне сховище (але ваша історія може бути не повною). Особисто я створив би сховище за проектом. Проекти часто мають кілька портлетів, і всі вони складаються в один і той же цикл проти тієї ж версії Liferay. Кожен проект може бути дублікатом існуючого проекту, який складається на основі іншої версії Liferay, але я б розділив продукт лише у випадку, якщо відмінності занадто великі. Якщо збірка працює проти Liferay 5.1 і 5.2, я б не розділяв проект. Я б використовував сценарії або Мейвен (або обидва), щоб все працювало. Я б використовував Wiki (або Trello) для управління кожним продуктом і з якою версією Liferay його можна побудувати.

До речі: я Java-програміст, спеціаліст Maven, спеціаліст зі зборки та маю досвід роботи з Liferay та іншими порталами серверів (IBM WebSphere та Glassfish).

Але це лише мої 0,02 євро.