Робота з гілками у SVN у блозі Особистий досвід розробки ПЗ

Робота з гілками в SVN

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

• Фіксація стану розробки (наприклад, випуск нової версії) до якого можна буде повернутися будь-якої миті.
• Розробка незалежно від основної гілки — актуальна, коли над проектом працюють кілька розробників.

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

Перед читанням рекомендую прочитати введення в Subversion і замітку про організацію репозиторію. Також слід переконатися, що версія SVN використовувана вами не нижче 1.5, оскільки більш ранні версії мають низку серйозних проблем у роботі з гілками.

Що таке гілка?

Договоримося, що під основною гілкою (стволом дерева) мається на увазі директорія в репозиторії, в якій йде розробка (trunk ). Тоді відразу ж після створення гілки вона представляє собою точну копію trunk, але незалежну від свого батька — стовбура дерева. Ви можете незалежно працювати і з гілкою і зі стовбуром, комити код у репозиторій, при цьому історія змін буде своя як для стовбура, так і для гілки. Гілки в SVN легковагні, тому ви можете створювати їх у будь-якій кількості, не особливо замислюючись про розростання репозиторію.

Фіксація певного стану розробки

Дуже зручно фіксувати певні стани розробки у гілках з ідентифікаторами відповідними до зовнішньої версії програмного забезпечення (наприклад 2.4.1) або внутрішньої (build_534). Ці ідентифікатори зручно використовувати в системах багтрекінгу, документації, внутрішньому листуванні. Можна бути впевненим, що будь-якої митічасу можна отримати потрібний стан коду, наприклад для дослідження причин виникнення проблеми.

Для цієї мети служить папкаtags докорінно репозиторію. Тобто всередині неї можуть бути папки з іменами1.0.0,1.0.1,2.0.0 і так далі, які у свою чергу будуть містити актуальний код на момент створення цієї гілки. Робота з ними повністю аналогічна роботі з trunk . Можливо вносити зміни, фіксувати їх у репозиторії, але я вкрай не рекомендую цього робити, оскільки концептуально це саме зліпки з основної гілки, що відповідають певному етапу!

Використання гілок під час колективної розробки

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

Для цих цілей я використовую директоріюbranches, таким чином ця директорія може містити тимчасові гілки наприклад такого виду:task_201,task_240 і так далі.

Створення гілки

Створити гілку просто, для цього треба створити копію основної гілки та закомітити зміни. Наприкладперебуваючи в корені репозиторію створимо тимчасову гілку:

Або створимо гілку відповідну випущеній версії 2.4.6:

Видалення гілки

Аналогічно видалення папки:

Злиття гілок

Після завершення роботи, необхідно злити зміни у тимчасовій гілці зі стволом. Найпростіше це зробити перейшовши в директорію з основною гілкою розробки (trunk ) і виконати командуmerge :

Після цього вирішити конфлікти (якщо були) і закинути зміни:

Перед виконанням злиття, по перше треба оновити код командоюupdate, а по-друге дуже бажано подивитися, що станеться при злитті не виконуючи його насправді:

Увага! Іноді, з незрозумілої для мене причини, при вказівці короткої форми шляху до гілки (../branches/ім'я_гілки ) злиття не працює, тому доводиться вказувати повний шлях:svn://server/ім'я_репозиторія/ branches/ім'я_гілки

Проблеми злиття гілок у SVN

Якщо у гілці чи стовбурі файл було видалено, перейменований чи переміщений, виникне конфлікт гілок (tree conflict). Автоматично вирішити цей конфлікт не вдасться, доведеться вручну перемістити файл (або навпаки не переміщати), вручну злити два файли і тільки після цього сказати системі, що конфлікт вирішено:

І закомітити зміни.

Ще трохи рекомендацій

З попереднього пункту можна дійти невтішного висновку, що конфлікт гілок штука вкрай неприємна і це справді так. Звідси дві рекомендації:

---