Чи корисно використовувати гілки для підтримки різних видань одного і того ж програмного забезпечення?

У нас є продукт, який має кілька різних видань. Відмінності незначні: різні рядки тут і там, дуже мало додаткової логіки в одному, дуже мало різниці в логіці в іншому. Коли розробляється програмне забезпечення, більшість змін потрібно додавати до кожного видання; однак, є кілька таких, які не мають, і кілька, що мають відрізнятись. Чи правильно використовувати гілки, якщо у мене є гілки релізу-editionA та релізи-виданняB (..etc)? Чи є якісь готчі? Хороші практики?

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

Це залежить від масштабу змін, але я б не вважав це доброю практикою щодо відмінностей, які ви описали.

Як правило, ви хочете, щоб гілка Git була чимось, що в майбутньому буде об'єднано або збережене лише для читання для ознайомлення. Гілки Git, які існують нескінченно, означають роботу для всіх: зміни потрібно поширювати та об'єднувати, вирішувати конфлікти, все весело. Якщо нічого іншого, кожен розробник повинен пам’ятати, щоби змінити п'ять сховищ замість одного.

Якщо у вас є невеликі зміни, цілі зусилля щодо об'єднання та утримання галузей здаються непосильними у порівнянні з проблемою. Використовуйте свій препроцесор або побудуйте систему для розмежування версій. Це простий #ifdefтрюк? Тоді не вирішуйте проблем з git, це надмірно.

Це не зовсім те, для чого потрібні гілки. Галузі повинні бути короткими до середньострокових бічних шляхів до вашої лінії розвитку, а не довгостроковими паралельними версіями того ж коду.

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

Адже ви хочете зберегти "єдине джерело істини"; з гілками, ви будете дублювати деякий код, але не всі, і певні злиття насправді порушили б налаштування.

Одне рішення - як зазначали люди - це налаштувати систему складання для підтримки різних видань.

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

Погляньте на цей сайт.

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

Це більше схоже на роботу для різних конфігурацій збірки. Відповідь Тітона йде в цьому напрямку, але я вважаю, що це набагато далі #ifdef:

Використовуйте різні цілі побудови для створення різних версій програмного забезпечення. Цілі можуть відрізнятися залежно від

• конфігурація, яку вони включають,
• об'єктні або вихідні файли, до яких вони входять, або
• попередня обробка вихідного коду.

Ця попередня обробка, очевидно, може включати класичний препроцесор C, але це також може спричинити використання спеціального препроцесора, шаблонного механізму для створення власних представлень,…

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

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

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

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

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