Відповіді:
Існує кілька застосувань для розгалуження. Одне з найпоширеніших застосувань - це відокремлення проектів, які колись мали загальну кодову базу. Це дуже корисно для експерименту зі своїм кодом, не впливаючи на основний магістраль.
Загалом, ви б бачили два типи галузей:
Функціональна галузь: Якщо певна функція є достатньо руйнівною, що ви не хочете, щоб на її ранній стадії впливала вся команда розробників, ви можете створити гілку, в якій виконувати цю роботу.
Fixes Branch: Незважаючи на те, що розробка продовжується в основному стволі, можна створити гілку виправлень, щоб містити виправлення останньої випущеної версії програмного забезпечення.
Можливо, вам буде цікаво переглянути наступну статтю, яка пояснює принципи розгалуження та коли їх використовувати:
Загалом, основна мета розгалуження (VCS - система управління версіями - особливість) - досягти ізоляції коду .
У вас є принаймні одна гілка, якої може бути достатньо для послідовної розробки, і вона використовується для багатьох завдань, що записуються (виконуються) на цій самій унікальній гілці.
Але ця модель швидко показує свою межу:
Якщо у вас є зусилля з розробки (рефакторинг, еволюція, виправлення помилок, ...) і ви розумієте, що не можете безпечно вносити ці зміни в ту саму гілку, ніж у вашій поточній гілці розробки (тому що ви зламаєте API або введете код, який порушить все), то вам потрібна інша гілка.
(Щоб виділити цей новий код від застарілого, навіть якщо два набори коду буде об’єднано пізніше)
Отже, це ваша відповідь саме там:
ви повинні розгалужуватися, коли не можете переслідувати та записувати два зусилля з розвитку в одній галузі.
(не маючи жахливо складної історії для підтримки).
Гілка може бути корисною, навіть якщо ви єдиний, хто працює над вихідним кодом, якщо вас багато.
Але ви не повинні робити "одну гілку на розробника":
мета "ізоляції" робиться для ізоляції зусиль з розробки (завдання, яке може бути настільки ж загальним, як "давайте розробимо наступну версію нашого програмного забезпечення", або настільки ж конкретним, як "давайте виправляємо помилка 23 "),
не ізолювати" ресурс " .
(гілка під назвою "VonC" нічого не означає для іншого розробника. Що робити, якщо "VonC" покине проект? Що ви з цим робити?
Гілка під назвою "bugfix_212" може бути інтерпретована, наприклад, у контексті системи відстеження помилок) , і будь-який розробник може використовувати його принаймні з деяким уявленням про те, що він повинен робити з цим)
Гілка не є тегом (SVN - це система редагування, яка намагається запропонувати функцію версій , наприклад розгалуження та теги через каталоги з дешевою копією файлу: це не означає, що тег є гілкою)
Визначити гілку означає також визначити робочий процес злиття : вам потрібно знати, де об’єднати свою гілку, коли ви закінчите з нею.
З цього приводу глава 7 практичної роботи (Laura WINGERD - O'Reilly) - це гарне введення (агностик VCS) для об'єднання робочого процесу між різними галузями: "" Як розвивається програмне забезпечення "(pdf)
Він визначає термін кодова лінія (гілка, яка записує значні етапи еволюції коду, або через теги в певних точках, або через важливе злиття назад до гілки).
Він представляє модель основної лінії (центральний код для запису випусків) та описує різні цілі розгалуження:
Інші цікаві концепції навколо VCS: основні поняття
(спочатку про ClearCase, але також дійсні для будь-яких VCS)
Усі СКМ 21 століття говорять вам:
Відділіться на кожне завдання, над яким ви працюєте , незалежно від того, чи це нова функція, виправлення, тест і все. Це називається галузевою темою, і це змінює спосіб роботи з вашим SCM.
Ви отримуєте:
Інструменти, які можуть це зробити:
Інструменти, які не можуть зробити це
Це також залежить від інструменту SCM, який ви використовуєте. Сучасні SCM (git, mercurial тощо) полегшують створення та знищення гілок, коли це необхідно. Це дозволяє, наприклад, робити одну гілку на помилку, над якою ви працюєте. Як тільки ви об’єднаєте свої результати в стовбур, ви відкинете гілку.
Інші СКМ, наприклад, субверсія та CVS, мають значно «важчішу» парадигму розгалуження. Це означає, що гілка вважається підходящою лише для чогось більшого, ніж двадцять-щось виправлення. Там гілки класично використовуються для відстеження цілих треків розвитку, як попередня або майбутня версія продукту.
Коли вам потрібно внести значні та / або експериментальні зміни в свою кодову базу, особливо якщо ви хочете здійснити проміжні зміни, не впливаючи на магістраль.
Це залежить від того, який тип SCM ви використовуєте.
У новіших розповсюджених версіях (наприклад, git і mercurial) ви постійно створюєте гілки і все одно перезавантажуєтесь. Я часто працюю над окремою гілкою деякий час лише тому, що хтось зламав збірку на магістралі або через те, що мережа перестала працювати, а потім об'єднати зміни в подальшому, коли це буде виправлено, і це так легко зробити, що це навіть не дратує .
Документ (короткий і читабельний), який найбільше допоміг мені зрозуміти, що відбувається в розподілених системах, це: UnderstandingMercurial .
У старих системах з центральним сховищем (наприклад, CVS, SVN та ClearCase), це набагато серйозніша проблема, яку потрібно вирішити на рівні команди, і відповідь має бути більше схожою на "підтримку старого випуску, дозволяючи розвиток, який слід продовжувати на основній лінії ", або" як частина великого експерименту ".
Я думаю, що розподілена модель набагато краща, і їй не вистачає лише гарних графічних інструментів, щоб стати домінуючою парадигмою. Однак це не так широко зрозуміло, і поняття різні, тому це може заплутати нових користувачів.
Я вважаю, що порада від Laura Wingerd & Christopher Seiwald в Perforce є дуже короткою та корисною:
* Branch only when necessary.
* Don't copy when you mean to branch.
* Branch on incompatible policy.
* Branch late.
* Branch, instead of freeze.
Детальне пояснення кожного з них та інших найкращих практик див. На веб-сайті http://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdf .
Для розгалуження існують різні цілі:
Кожного разу, коли вам це подобається.
Ви, мабуть, не дуже часто працюєте з централізованою SCM, оскільки гілки є частиною офіційного сховища, і це насправді не вимагає великих експериментів, не кажучи вже про те, що злиття дуже боляче.
OTOH, немає ніякої технічної різниці між відділенням і замовленням в розподілених SCM, і злиття набагато простіше. Ви будете відчувати, як розгалужуватись набагато частіше.
Коли вам потрібно внести зміни на основі вашої поточної гілки, не призначеної для наступного випуску з цієї гілки (і не раніше).
Наприклад, ми зазвичай працюємо над багажником. Приблизно під час виходу комусь потрібно буде внести зміни, які ми не хочемо в поточному випуску (це може бути до випуску, на даний момент це зазвичай після виходу). Це коли ми розгалужуємо, щоб поставити реліз на власну гілку та продовжити розробку наступного випуску на магістралі.