Великий макет проекту: додавання нової функції для кількох підпроектів

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

У моєму поточному проекті є 4 основні частини.

1. Веб
2. Сервер
3. Консоль адміністратора
4. Платформа.

Частина Інтернету та сервера використовує 2 бібліотеки, які я написав. Всього є 5 сховищ git та 1 сховище mercurial. Сценарій створення проекту знаходиться у сховищі платформи. Це автоматизує весь процес будівництва.

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

Тож я повинен створити єдине репо і помістити туди всі компоненти? Я думаю, що в такому випадку розгалуження буде простішим. Або я просто роблю те, що зараз роблю. У такому випадку як я вирішую цю проблему створення філії на кожному сховищі?

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

Рішення полягає в тому, щоб визначити структуру вашого сховища на основі з’єднання коду всередині нього: якщо компонент проекту A має лише стійкі інтерфейси з компонентом проекту B, вони можуть бути розміщені в окремих сховищах. В іншому випадку вони повинні бути розміщені спільно в одному сховищі. Більш деталізований макет сховища відображатиме кращу структуру системної архітектури.

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

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

Якщо всі сховища дійсно є частиною одного проекту (вони не можуть стояти окремо), то, можливо, вам слід мати лише 1 сховище. (А може бути 2: основний проект та проект із загальної / стандартизованої функціональності.)