Что означают "ветвь", "тег" и "ствол" в репозиториях Subversion?
Я часто видел эти слова в дискуссиях о Subversion (и, я думаю, в общем хранилище). Я использовал SVN для своих проектов последние несколько лет, но я никогда не понимал полную концепцию этих каталогов.
Что они имеют в виду?
16 ответов
Хм, не уверен, что я согласен с тем, что Ник ре тег похож на ветку. Тег это просто маркер
Магистраль будет основной частью разработки, начиная с начала проекта до настоящего времени.
Ветвь будет копией кода, полученного из определенной точки в стволе, который используется для внесения основных изменений в код при сохранении целостности кода в стволе. Если основные изменения работают в соответствии с планом, они обычно объединяются обратно в магистраль.
Метка будет моментом времени на стволе или ветви, которую вы хотите сохранить. Двумя основными причинами сохранения будет то, что это либо основной выпуск программного обеспечения, будь то альфа, бета, RC или RTM, либо это самый стабильный вариант программного обеспечения до того, как были применены основные изменения в магистрали.
В проектах с открытым исходным кодом основные ветви, которые не принимаются заинтересованными сторонами проекта, могут стать основой для форков - например, полностью отдельные проекты, имеющие общее происхождение с другим исходным кодом.
Прежде всего, как указывают @AndrewFinnell и @KenLiu, в SVN имена каталогов сами по себе ничего не значат - "ствол, ветви и теги" - это просто общее соглашение, которое используется большинством репозиториев. Не во всех проектах используются все каталоги (достаточно часто вообще не использовать "теги"), и на самом деле ничто не мешает вам называть их как угодно, хотя нарушение соглашения часто сбивает с толку.
Я опишу, вероятно, наиболее распространенный сценарий использования веток и тегов, и приведу пример сценария их использования.
Багажник: основное направление развития. Это место, где живет ваш следующий основной выпуск кода, и, как правило, имеет все новейшие функции.
Ветви: Каждый раз, когда вы выпускаете основную версию, создается ветка. Это позволяет вам исправлять ошибки и создавать новые версии, не выпуская новейшие (возможно, незавершенные или непроверенные) функции.
Теги: каждый раз, когда вы выпускаете версию (финальный выпуск, релиз-кандидаты (RC) и бета-версии), вы создаете тег для нее. Это дает вам на момент времени копию кода, которая была в этом состоянии, позволяя вам вернуться и воспроизвести любые ошибки, если это необходимо в предыдущей версии, или переиздать предыдущую версию в точности так, как это было. Ветви и теги в SVN облегчены - на сервере он не создает полную копию файлов, а просто маркер, говорящий "эти файлы были скопированы с этой ревизией", занимающий всего несколько байтов. Имея это в виду, вы никогда не должны беспокоиться о создании тега для любого выпущенного кода. Как я уже говорил ранее, теги часто опускаются, и вместо этого, журнал изменений или другой документ уточняет номер редакции при выпуске.
Например, допустим, вы начинаете новый проект. Вы начинаете работать в "стволе", над чем в конечном итоге будет выпущена версия 1.0.
- trunk / - версия для разработки, скоро будет 1.0
- ветви / - пусто
Как только 1.0.0 закончен, вы ветвитесь на ствол в новую ветку "1.0" и создаете тег "1.0.0". Теперь работа над тем, что в итоге будет 1.1, продолжается в багажнике.
- trunk / - версия для разработки, скоро будет 1.1
- ветки /1.0 - версия 1.0.0
- tags/1.0.0 - версия 1.0.0
Вы сталкиваетесь с некоторыми ошибками в коде и исправляете их в стволе, а затем объединяете исправления с веткой 1.0. Вы также можете сделать обратное и исправить ошибки в ветке 1.0, а затем объединить их обратно в транк, но обычно проекты придерживаются одностороннего объединения только для уменьшения шансов что-то упустить. Иногда ошибка может быть исправлена только в 1.0, потому что она устарела в 1.1. На самом деле это не имеет значения: вам нужно только убедиться, что вы не выпускаете 1.1 с теми же ошибками, которые были исправлены в 1.0.
- trunk / - версия для разработки, скоро будет 1.1
- ветки /1.0 - предстоящая версия 1.0.1
- tags/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.
- trunk / - версия для разработки, скоро будет 1.1
- ветки /1.0 - предстоящая версия 1.0.2
- tags/1.0.0 - версия 1.0.0
- tags/1.0.1 - версия 1.0.1
В конце концов вы почти готовы к выпуску 1.1, но сначала вы хотите сделать бета-версию. В этом случае вы, скорее всего, сделаете ветку "1.1" и тег "1.1beta1". Теперь работа над тем, что будет 1.2 (или, может быть, 2.0), продолжается в транке, но работа над 1.1 продолжается в ветке "1.1".
- trunk / - версия для разработки, скоро будет 1.2
- ветки /1.0 - предстоящая версия 1.0.2
- ветки /1.1 - предстоящая версия 1.1.0
- tags/1.0.0 - версия 1.0.0
- tags/1.0.1 - версия 1.0.1
- tags/1.1beta1 - 1.1 бета 1 версия выпуска
Выпустив финальную версию 1.1, вы делаете тег "1.1" из ветки "1.1".
Вы также можете продолжить поддерживать 1.0, если хотите, портируя исправления ошибок между всеми тремя ветвями (1.0, 1.1 и trunk). Важно отметить, что для каждой основной версии программного обеспечения, которую вы поддерживаете, у вас есть ветвь, которая содержит самую последнюю версию кода для этой версии.
Другое использование веток для функций. Здесь вы ветвитесь в ствол (или одну из веток релиза) и работаете над новой функцией изолированно. Как только функция завершена, вы объединяете ее обратно и удаляете ветку.
- trunk / - версия для разработки, скоро будет 1.2
- ветки /1.1 - предстоящая версия 1.1.0
- ветки /ui-rewrite - экспериментальная ветка
Идея этого заключается в том, что вы работаете над чем-то разрушительным (что может задержать или мешать другим людям выполнять свою работу), чем-то экспериментальным (что может даже не быть выполнено) или, возможно, просто чем-то, что занимает много времени (и вы боитесь, что если он будет поддерживать релиз 1.2, когда вы будете готовы к ветке 1.2 из транка), вы можете сделать это изолированно в ветке. Как правило, вы поддерживаете его в актуальном состоянии с транком, постоянно объединяя изменения, что облегчает повторную интеграцию (слияние обратно в транк), когда вы закончите.
Также обратите внимание, что схема управления версиями, которую я здесь использовал, является лишь одной из многих. Некоторые команды могут делать исправления ошибок / выпуски поддержки как 1.1, 1.2 и т. Д., А основные изменения - как 1.x, 2.x и т. Д. Здесь используется то же самое, но вы можете назвать ветку "1" или "1"..x"вместо" 1.0 "или"1.0.x". (Кроме того, семантическое управление версиями является хорошим руководством о том, как делать номера версий).
В дополнение к тому, что сказал Ник, вы можете узнать больше на Streamed Lines: паттерны ветвления для параллельной разработки программного обеспечения
На этом рисунке main это багажник, rel1-maint это филиал и 1.0 это тег
В общем (инструментальное представление) ветвь - это механизм, используемый для параллельной разработки. SCM может иметь от 0 до n ветвей. Subversion имеет 0.
Trunk - это основная ветка, рекомендованная Subversion, но вы никоим образом не обязаны ее создавать. Вы могли бы назвать это "главным" или "выпусками", или не иметь ни одного вообще!
Филиал представляет собой усилия по развитию. Он никогда не должен быть назван в честь ресурса (например, vonc_branch), но после:
- цель "myProject_dev" или "myProject_Merge"
- периметр выпуска 'myProjetc1.0_dev' или myProject2.3_Merge'или'myProject6..2_Patch1'...
Тег - это снимок файла, чтобы легко вернуться в это состояние. Проблема в том, что тег и ветвь одинаковы в Subversion. И я определенно рекомендую параноидальный подход:
Вы можете использовать один из сценариев контроля доступа, поставляемых с Subversion, чтобы никто не делал ничего, кроме создания новых копий в области тегов.
Тег является окончательным. Его содержание никогда не должно меняться. НИКОГДА. Когда-либо. Вы забыли строку в заметке о выпуске? Создать новый тег. Устаревший или удалить старый.
Теперь я много читал о "объединении таких-то и таких-то в таких-то ветках и, наконец, в ветке ствола". Это называется рабочим процессом слияния, и здесь нет ничего обязательного. Не потому, что у вас есть ветвь ствола, вы должны что-то объединить.
По соглашению, ветвь ствола может представлять текущее состояние вашей разработки, но это для простого последовательного проекта, то есть проекта, который имеет:
- нет "заблаговременной" разработки (для подготовки следующей-следующей версии, подразумевающей такие изменения, что они несовместимы с текущей "магистральной" разработкой)
- без масштабного рефакторинга (для тестирования нового технического выбора)
- нет долгосрочного обслуживания предыдущего выпуска
Потому что с одним (или всеми) из этого сценария вы получаете четыре "ствола", четыре "текущих разработки", и не все, что вы делаете в этой параллельной разработке, обязательно должны быть объединены обратно в "ствол".
В SVN тег и ветка действительно похожи.
Tag = определенный фрагмент времени, обычно используемый для релизов
Ветвь = также определенный отрезок времени, на котором может продолжаться разработка, обычно используемая для основной версии, такой как 1.0, 1.5, 2.0 и т. Д., Затем, когда вы отпускаете, вы отмечаете ветку. Это позволяет вам продолжать поддерживать производственную версию, в то же время продвигаясь вперед с серьезными изменениями в стволе.
Магистраль = рабочее пространство для разработки, именно здесь должна происходить вся разработка, а затем изменения объединяются с выпусками веток.
Они действительно не имеют никакого формального значения. Папка - это папка для SVN. Они являются общепринятым способом организации вашего проекта.
Ствол - это то место, где вы храните свою основную линию развития. Папка веток - это место, где вы можете создавать ветки, которые сложно объяснить в коротком посте.
Ветвь - это копия подмножества вашего проекта, над которой вы работаете отдельно от ствола. Может быть, это для экспериментов, которые могут никуда не пойти, или, может быть, это для следующего выпуска, который вы позже объедините обратно в ствол, когда он станет стабильным.
А папка tags предназначена для создания помеченных копий вашего хранилища, обычно на контрольных точках выпуска.
Но, как я уже сказал, для SVN папка - это папка. branch, trunk а тег - это просто соглашение.
Я использую слово "копировать" свободно. SVN на самом деле не делает полные копии вещей в хранилище.
Магистраль - это линия разработки, которая содержит новейший исходный код и функции. Он должен иметь последние исправления ошибок, а также последние функции, добавленные в проект.
Ветви обычно используются, чтобы сделать что-то вдали от ствола (или другой линии разработки), что в противном случае нарушило бы сборку. Новые функции часто встроены в ветку, а затем объединены обратно в ствол. Ветви часто содержат код, который не обязательно одобрен для той ветки разработки, из которой он ветвился. Например, программист может попробовать оптимизировать что-то в ветке и слиться с линией разработки только после того, как оптимизация окажется удовлетворительной.
Теги являются снимками хранилища в определенное время. Никакого развития не должно происходить на них. Они чаще всего используются для получения копии того, что было передано клиенту, чтобы вы могли легко иметь доступ к тому, что использует клиент.
Вот ссылка на очень хорошее руководство по репозиториям:
Статьи в Википедии также стоит прочитать.
В том-то и дело, что в разработке программного обеспечения нет последовательных знаний ни о чем, у всех, кажется, все по-своему, но это потому, что в любом случае это относительно молодая дисциплина.
Вот мой простой способ,
trunk - каталог trunk содержит самый актуальный, утвержденный и объединенный объем работ. Вопреки тому, что многие признались, мой багажник предназначен только для чистой, аккуратной, одобренной работы, и не для разработки, а для освобождения.
В определенный момент времени, когда кажется, что ствол полностью готов к выпуску, он помечается и освобождается.
ветки - каталог веток содержит эксперименты и текущую работу. Работа под веткой остается там до тех пор, пока не будет одобрен для слияния в ствол. Для меня это та область, где вся работа выполнена.
Например: у меня может быть ветвь итерации-5 для пятого раунда разработки продукта, может быть ветка -прототип-9 для девятого раунда экспериментов и так далее.
теги - каталог тегов содержит снимки утвержденных веток и выпусков стволов. Всякий раз, когда ветвь одобрена для слияния со стволом или выпускается ствол, снимок утвержденного ветвления или выпуска ствола делается под тегами.
Я полагаю, что с помощью тегов я могу прыгать назад и вперед во времени к интересующим точкам.
Я нашел этот замечательный учебник по SVN, когда искал веб-сайт автора книги по программированию приложений OpenCV 2 Computer Vision, и подумал, что должен поделиться.
У него есть учебник о том, как использовать SVN и что означают фразы "ствол", "тег" и "ветвь".
Цитируется прямо из его урока:
Текущая версия вашего программного проекта, над которой сейчас работает ваша команда, обычно находится в каталоге с именем trunk. По мере развития проекта разработчик обновляет эту версию, исправляет ошибки, добавляет новые функции) и отправляет свои изменения в этот каталог.
В любой момент времени вы можете захотеть заморозить версию и сделать снимок программного обеспечения в том виде, в каком оно находится на данном этапе разработки. Как правило, это соответствует официальным версиям вашего программного обеспечения, например, версиям, которые вы будете предоставлять своим клиентам. Эти снимки находятся в каталоге тегов вашего проекта.
Наконец, в какой-то момент полезно создать новую линию разработки для вашего программного обеспечения. Это происходит, например, когда вы хотите протестировать альтернативную реализацию, в которой вам нужно изменить свое программное обеспечение, но вы не хотите отправлять эти изменения в основной проект, пока не решите, принимаете ли вы новое решение. Затем основная команда может продолжить работу над проектом, в то время как другие разработчики работают над прототипом. Вы бы поместили эти новые линии развития проекта в каталог под названием ветки.
Магистральный каталог - это каталог, с которым вы, вероятно, больше всего знакомы, поскольку он используется для хранения самых последних изменений. Ваша основная кодовая база должна быть в транке.
Каталог ветвей предназначен для хранения ваших веток, какими бы они ни были.
Каталог тегов в основном предназначен для маркировки определенного набора файлов. Вы делаете это для таких вещей, как выпуски, где вы хотите, чтобы "1.0" были этими файлами в этих ревизиях, а "1.1" - этими файлами в этих ревизиях. Обычно вы не изменяете теги после их создания. Для получения дополнительной информации о тегах см. Глава 4. Ветвление и слияние (в разделе Управление версиями с помощью Subversion).
Одна из причин, почему у каждого есть немного другое определение, заключается в том, что Subversion реализует нулевую поддержку ветвей и тегов. Subversion в основном говорит: мы смотрели на полнофункциональные ветви и теги в других системах и не нашли их полезными, поэтому мы ничего не реализовали. Просто сделайте копию в новый каталог с соглашением об именах. Тогда, конечно, каждый волен иметь немного разные соглашения. Чтобы понять разницу между реальным тегом и простым соглашением об именовании и копировании, см. Статью и ветви Subversion в Википедии.
Tag = определенный фрагмент времени, обычно используемый для релизов
Я думаю, это то, что обычно подразумевают под "тегом". Но в Subversion:
Они действительно не имеют никакого формального значения. Папка - это папка для SVN.
что я нахожу довольно запутанным: система контроля версий, которая ничего не знает о ветвях или тегах. С точки зрения реализации, я думаю, что способ создания "копий" в Subversion очень умный, но мне нужно знать об этом, что я бы назвал дырявой абстракцией.
Или, может быть, я просто слишком долго использовал CVS.
Я думаю, что некоторая путаница возникает из-за разницы между концепцией тега и реализацией в SVN. Для SVN тег - это ветка, которая является копией. Изменение тегов считается неправильным, и на самом деле такие инструменты, как TortoiseSVN, будут предупреждать вас, если вы попытаетесь изменить что-либо с помощью../tags/.. в пути.
Я не совсем уверен, что такое "тег", но ветвь является довольно распространенной концепцией управления исходным кодом.
По сути, ветвь - это способ работать над изменениями кода, не затрагивая ствол. Скажем, вы хотите добавить новую довольно сложную функцию. Вы хотите иметь возможность регистрировать изменения по мере их внесения, но не хотите, чтобы они влияли на транк, пока вы не закончили с этой функцией.
Сначала вы создадите ветку. Это в основном копия ствола на момент создания ветки. Затем вы сделаете всю свою работу в филиале. Любые изменения, сделанные в ветви, не влияют на транк, поэтому транк по-прежнему пригоден для использования, что позволяет другим продолжать работать там (например, исправление ошибок или небольшие улучшения). Как только ваша функция будет готова, вы сможете интегрировать ветку обратно в транк. Это переместит все ваши изменения из ветви в ствол.
Есть несколько шаблонов, которые люди используют для веток. Если у вас есть продукт с поддержкой нескольких основных версий одновременно, обычно каждая версия будет ветвью. Там, где я работаю, у нас есть отдел QA и производственный отдел. Перед выпуском нашего кода в QA мы интегрируем изменения в ветку QA, а затем внедряем их. Выпуская в производство, мы интегрируемся из ветви QA в ветку Production, поэтому мы знаем, что код, работающий в рабочей среде, идентичен тому, что тестировал QA.
Вот запись в Википедии о ветвях, поскольку они, вероятно, объясняют вещи лучше, чем я.:)
Багажник: после завершения каждого спринта в agile мы выпускаем частично отгружаемый продукт. Эти релизы хранятся в багажнике.
Ветви: Все параллельные коды разработки для каждого текущего спринта хранятся в ветвях.
Теги: каждый раз, когда мы выпускаем частично бета-версию продукта, мы делаем для него тег. Это дает нам код, который был доступен в тот момент, позволяя нам вернуться в это состояние, если это потребуется в какой-то момент в процессе разработки.
Для людей, знакомых с GIT, мастер в GIT эквивалентен транку в SVN.
Ветвь и тег имеют одинаковую терминологию как в GIT, так и в SVN.
Магистраль - это базовая папка кода вашего приложения. Именно здесь вы работаете над своей следующей версией / выпуском.
Ветвь - это папка, которая позволяет вам выбирать момент времени и идти другим путем, нежели /Trunk. Распространенным использованием Branch является предоставление вашей команде разработчиков доступа к текущему снимку вашего приложения, как он существует в производственной среде, т.е. / Отрасль / производство, обслуживание.
Эта концепция "ветвления" позволяет вашей команде создавать исправления / улучшения в работе, не влияя на текущую работу над следующей версией, которая в настоящее время происходит в /Trunk. Ветви также могут быть мини-частями функциональности, которые в больших командах позволяют разработчикам работать атомарно и в будущем вернуться к /Trunk.
Теги - это папка, которая позволяет делать снимки вашего приложения и работать только с этими конкретными "сборками". Это обеспечивает гибкость вашей команды как в тестировании, так и в поиске различий между сборками. В / Branch вы часто встречаете соглашение об именах, которое относится к вашим сборкам, т.е. /Branch/2.0.0, /Branch/2.0.1, /Branch/3.1.0 и т. Д. Соглашение об именах зависит от вас и вашей команды; Держите это последовательным!