Перш за все, як зазначають @AndrewFinnell та @KenLiu, у SVN імена каталогів самі по собі нічого не означають - "стовбур, гілки та теги" - це просто звичайна умова, яка використовується більшістю сховищ. Не всі проекти використовують усі каталоги (досить часто взагалі не використовувати «теги»), і насправді ніщо не заважає вам називати їх усім, що вам хотілося б, хоча порушення конвенції часто бентежить.
Я опишу, мабуть, найпоширеніший сценарій використання гілок і тегів, і наведу приклад сценарію того, як вони використовуються.
Багажник : Основна зона розвитку. Тут проживає ваш наступний головний випуск коду і, як правило, є всі новітні функції.
Гілки : Щоразу, коли випускаєте основну версію, вона створюється гілкою. Це дозволяє робити виправлення помилок та робити новий реліз, не випускаючи нові - можливо незавершені чи неперевірені - функції.
Теги : Щоразу, коли випускаєте версію (остаточний реліз, випуск кандидатів (RC) та бета-версії), ви робите тег для неї. Це дає точну копію коду, як він був у тому стані, що дозволяє вам повернутися назад і відтворити будь-які помилки, якщо це необхідно, в минулій версії, або повторно випустити попередню версію саме такою, якою вона була. Гілки та теги в SVN легкі - на сервері він не робить повну копію файлів, лише маркер, який говорить "ці файли були скопійовані під час цього перегляду", який займає лише кілька байт. Зважаючи на це, ви ніколи не повинні турбуватися про теги для будь-якого випущеного коду. Як я вже говорив раніше, теги часто опускаються, і замість цього, журнал змін або інший документ уточнює номер версії, коли робиться випуск.
Наприклад, скажімо, ви починаєте новий проект. Ви починаєте працювати в "магістралі", над тим, що з часом вийде у версії 1.0.
- trunk / - версія розробки, незабаром буде 1,0
- гілки / - порожні
Після завершення 1.0.0 ви розгалужуєте стовбур нової гілки "1.0" та створюєте тег "1.0.0". Тепер робота над тим, що в підсумку буде 1,1, продовжується в магістралі.
- магістраль / - версія розробки, скоро буде 1.1
- відділення / 1.0 - версія 1.0.0
- теги / 1.0.0 - версія 1.0.0 випуску
Ви натрапляєте на деякі помилки в коді та виправляєте їх у магістралі, а потім об'єднуєте виправлення у відділення 1.0. Ви також можете зробити навпаки, і виправити помилки у відділенні 1.0, а потім об'єднати їх назад до стовбура, але зазвичай проекти дотримуються злиття в один бік, щоб зменшити шанс чогось пропустити. Іноді помилку можна виправити лише у 1,0, оскільки вона є застарілою у 1.1. Це насправді не має значення: ви хочете лише переконатися, що ви не випустите 1.1 з тими ж помилками, які були виправлені в 1.0.
- магістраль / - версія розробки, скоро буде 1.1
- відділення / 1.0 - майбутній випуск 1.0.1
- теги / 1.0.0 - версія 1.0.0 випуску
Виявивши достатню кількість помилок (або, можливо, одну критичну помилку), ви вирішите зробити випуск 1.0.1. Отже, ви робите тег "1.0.1" з відділення 1.0 і випускаєте код. У цей момент магістраль буде містити те, що буде 1,1, а гілка "1,0" містить код 1,0.1. Наступного разу, коли ви випустите оновлення до версії 1.0, це буде 1.0.2.
- магістраль / - версія розробки, скоро буде 1.1
- відділення / 1.0 - майбутній випуск 1.0.2
- теги / 1.0.0 - версія 1.0.0 випуску
- теги / 1.0.1 - версія версії 1.0.1
Зрештою ви майже готові випустити 1.1, але спочатку хочете зробити бета-версію. У цьому випадку ви, ймовірно, зробите гілку "1.1" та тег "1.1beta1". Тепер робота над рівнем 1,2 (або, можливо, 2,0) продовжується в магістралі, але робота над 1.1 триває в гілці "1.1".
- магістраль / - версія розробки, скоро буде 1.2
- відділення / 1.0 - майбутній випуск 1.0.2
- гілки / 1.1 - майбутній випуск 1.1.0
- теги / 1.0.0 - версія 1.0.0 випуску
- теги / 1.0.1 - версія версії 1.0.1
- теги / 1.1beta1 - 1.1 версія бета-версії 1
Після випуску 1.1 фіналу ви робите тег "1.1" з гілки "1.1".
Ви також можете продовжувати підтримувати 1,0, якщо хочете, переносячи виправлення помилок між усіма трьома гілками (1.0, 1.1 та стовбуром). Важливим рішенням є те, що для кожної основної версії програмного забезпечення, яке ви підтримуєте, у вас є відділення, яке містить останню версію коду для цієї версії.
Ще одне використання гілок - для функцій. Тут ви здійснюєте відділення магістралі (або одного з відділень випуску) та працюєте над новою функцією ізольовано. Після завершення функції ви об’єднуєте її назад і виймаєте гілку.
- магістраль / - версія розробки, скоро буде 1.2
- гілки / 1.1 - майбутній випуск 1.1.0
- гілки / ui-переписати - гілка експериментальної функції
Ідея цього полягає в тому, коли ви працюєте над чимось руйнівним фактором (яке б стримувало чи заважало іншим людям виконувати свою роботу), щось експериментальне (що може навіть не встигнути) або, можливо, просто щось, що потребує тривалого часу (і ви боїтесь, якщо він містить 1.2 випуску, коли ви готові відгалужувати 1.2 від магістралі), ви можете це зробити ізольовано у гілці. Як правило, ви постійно оновлюєте його магістраллю, постійно об'єднуючи зміни, що полегшує повторну інтеграцію (злиття назад до магістралі), коли ви закінчите.
Також зауважте, що використана тут схема версій - лише одна з багатьох. Деякі команди виконують виправлення помилок / випуски технічного обслуговування як 1.1, 1.2 та ін., А також значні зміни, як 1.x, 2.x, тощо. Використання тут те саме, але ви можете назвати гілку "1" або "1 .x "замість" 1.0 "або" 1.0.x ". (Окрім того, семантична версія є хорошим посібником щодо того, як робити номери версій).
