Чи варто турбуватися з гілками SVN, якщо у вас є лише колись?

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

Ось як ми розвиваємось із Subversion:

• Є стовбур
• Ми робимо нову галузь розвитку
• Ми розробляємо нову особливість у цій галузі
• Коли функція виконана, вона об'єднується в стовбур, гілка видаляється і з стовбура робиться нова гілка розвитку

Коли ми хочемо випустити на виробництво, ми робимо бирку з магістралі. Виправлення помилок зроблені на гілці з цього тегу. Потім ця помилка об'єднується в багажник.

Ось чому ми робимо нову галузь розвитку після того, як функція буде виконана. Таким чином, виправлення буде включено досить швидко до нашого нового коду.

Нижче наведена схема, яка повинна уточнити:

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

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

Потім, коли функція 1 закінчена, вона об'єднується в магістраль, але включається деякі елементи функції 2.

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

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

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

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

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

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

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